Liaison statement
IETF CCAMP Response to Liaison on MFA CNI
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2006-11-30 |
From Group | IETF |
From Contact | Matthew Bocci |
To Group | MFA-FORUM |
To Contacts | Rao Cherukuri <cherukuri@juniper.net> |
Cc | CCAMP Mailing list <ccamp@ops.ietf.org> Ross Callon <rcallon@juniper.net> Bill Fenner <fenner@research.att.com> Adrian Farrel <adrian@olddog.co.uk> Deborah Brungard <dbrungard@att.com> |
Response Contact | Adrian Farrel <adrian@olddog.co.uk> Deborah Brungard <dbrungard@att.com> |
Technical Contact | Adrian Farrel <adrian@olddog.co.uk> Deborah Brungard <dbrungard@att.com> |
Purpose | In response |
Attachments | (None) |
Body |
Dear Rao, Thank you very much for giving the CCAMP working group the opportunity to comment on the MFA's MPLS CNI specification. At this stage we have the following high-level comments that we request the MFA to consider and answer. Some of these comments are for clarification as we try to ramp-up on the requirements you are addressing. Others concern technical issues that we feel you should address before advancing this work. Best regards, Adrian Farrel and Deborah Brungard CCAMP Working Group Co-Chairs === We note that you have opted to define a new RSVP object to support a multi-class LSP following the rules for vendor private assignment as described in section 2.2 of RFC3936. We believe that you may have misinterpreted the purpose of vendor private extensions since such extensions are specifically not intended to interoperate, but you are attempting to define a specification directly for the purpose of interworking devices from different vendors. In your case it would seem to make more sense to define a standardized extension to the protocol. Should you decide that a standardized extension is better able to deliver the functionality that you require, we should like to draw your attention to draft-andersson-rtg-gmpls-change-06.txt that defines how other SDOs may influence the development of MPLS and GMPLS protocols within the IETF, and which is currently in IETF last call. The (G)MPLS suites of protocols have become popular among multiple SDOs resulting in a need for IETF to clarify it's role as the responsible SDO for (G)MPLS protocol extensions so as to prevent unnecessary replication of functionality and the resulting interoperability problems. 1. The document is marked as Straw Ballot Text. Can you tell us what that means the status of the work is? 2. We think that your use of terminology may be a little loose. In many cases, where you say "MPLS" you are probably referring to the data plane, and specifically a packet-switching data plane with an MPLS encapsulation. But in other cases, "MPLS" and "MPLS-TE" are synonymous and refer to a signaling/routing control plane using the MPLS-TE extensions to RSVP and to the two IGPs OSPF and IS-IS. In many cases you say "GMPLS-TE" which is not something we specifically recognise although we can assume that you mean simply "GMPLS". Sometimes, where you are trying to distinguish a TE LSP established using MPLS-TE from one set up using GMPLS you may intend to say "GMPLS TE-LSP" rather than "GMPLS-TE LSP". We feel that close attention to the terminology may help clarify the document. 3. Section 1.1 states: The purpose of this specification is to define an MPLS-based Client to Network Interconnect (CNI) for establishing GMPLS Traffic Engineered (TE) Label Switched Paths (LSPs). Can we assume that this means that the client-to-client LSPs are established using GMPLS protocols, but that the signaling within the core network is out of scope? Especially since section 1.2 states: At the CNI, it is not desirable to have the client equipment participate in the internal control protocols of the MPLS network. 4. Can you clarify why you have selected GMPLS protocols and not MPLS-TE protocols on which to build your CNI. We are not opposed to this, but are seeking to understand the choice. Perhaps the main reason is the requirement for bidirectional LSPs. 5. Can you clarify whether the core network is assumed to be PSC only? That is, for example, if the CNI encoding is POS, would it be acceptable for the PE and the rest of the core network to switch the LSP as TDM until the remote PE or even CE, or do you require that the PE must perform packet switching? If the PE must perform packet switching, is it still acceptable for the core LSP (PE-PE) to be switched at some other technology? 6. Section 1.3 states: Where the network uses MPLS-TE signaling, the PE routers are expected to perform the translation. It is our opinion that this translation is non-trivial and may be impossible for some of the GMPLS services that are available at the CNI. For example, supporting a bidirectional service over an MPLS-TE signaling network requires additional coordination between the end-points that is currently not available in the MPLS-TE extensions to RSVP-TE. From the following text in section 7.1, we assume that the PE may refuse a CNI request if it is unable to provide the required level of function. The transport network in the provider network is a GMPLS or MPLS-TE based packet switched network that must support request for uni-directional LSPs and may support requests for bi-directional LSPs 7. Section 2.1 The correct expansion of "GMPLS" is "Generalized Multiprotocol Label Switching". In view of you chosen expansion of "MPLS", you may prefer to show this as "Generalized Multi Protocol Label Switching". The correct expansion of "FEC" is "Forwarding Equivalence Class". 8. Section 7.2 states: The CE and PE nodes are inter-connected by point-to-point interfaces. The signaling channel is "in-band", i.e., the labeled packets share the same access connection as the RSVP-TE signaling. This is an acceptable, but not required, method of deploying GMPLS-based signaling. It is our suspicion reading this very short section that it is your intention to forbid the use of the IF_ID RSVP_HOP Object at the CNI. Can you confirm or deny this? 9. Section 7.3 states: A client need only know its own address, a reachable address of the adjacent PE-node, and know the address of any other client to which it wishes to connect. The addresses listed above must be configured on each client. A PE need only know (and track) the addresses on interfaces attached to clients, as well as the Node IDs of these attached clients. In addition, the IP/MPLS network needs to know reachability to the interface addresses and Node IDs of other PEs to which an attached client is permitted to connect. This appears to miss the fact that the client will address a CNI connection request to a remote client address. The local PE must, therefore, know how to route to these client addresses that are outside the core routing domain. Perhaps the final sentence should say CE not PE? But in 9.1.2 you have: When a PE receives a Path message from a client that contains no ERO indicating transit network selection, then the PE is responsible for progressing the Path message toward the destination. The progression of the Path message is beyond the scope of this specification. While the details are clearly out of scope, it *is* relevant to the definition of the CNI how the core acquires and distributes the client-side addressing information that is necessary for routing across the core. You will observe that the problem you are solving (including the fact that the client addresses may come from an address space that overlaps with the core address space) is similar to the L3VPN problem. 10. What is the expected behavior from the core network when an E-LSP is requested at the CNI? Can we assume that the expectation is that an appropriate E-LSP will also be established across the core so that Diffserv behavior will be performed along the whole length of the client-client connection, or is this not a requirement? If core Diffserv behavior is required, how will the core handle the presence of multiple classes? 11. You are correct to observe that the ERO is optional in GMPLS implementations (sections 9.1.1 and 9.1.2), however, since you are specifying a profile for use at the CNI, and since both the CE and the PE must be CNI-aware (i.e., you cannot simply use legacy implementations) you may find it convenient to mandate support of the ERO at the CNI. We believe that in practice all implementations support ERO. 12. In section 9.1.1 you have: The client populates the ERO object with only one sub-object containing an Autonomous System Number (ASN) representing a transit network beyond the originating service provider. The client equipment must set the ASN sub-object 'L' bit to 1, indicating a loose route. It is not completely clear what is meant by 'the originating service provider', but we assume that this refers to the network that the ingress PE belongs to. In this case, this ERO is malformed and will be rejected. The first sub-object of a received ERO must always define an abstract node that the receiver is a member of. See RFC 3209, section 4.3.4.1, point 1). 13. In section 9.4: PE next to a client receives a PathErr with Path_State_Removed from the network, it may in turn generate either a ResvTear or PathTear, whichever is applicable, to be sent to the client. There are no circumstances in which a PE receiving a PathErr with Path_State_Removed from the network would send PathTear to the client. It is unclear to us why you would specify that the CNI built on GMPLS might not use this standard GMPLS procedure. 14. In section 9.5.3: The Extended Classtype object is signaled in the Path message, and saved in the Path State Block (PSB) at every hop. We recommend that you simply state that the state is stored as every hop. The existence of a PSB is implementation- specific. Can you please clarify "at every hop". Are you expecting nodes in the core network to store this information. If so, you should note that the core nodes will not recognize the object class and will reject any messages carrying it. We also suggest that before progressing your own extensions for multi-class DSTE LSPs you should look at the existing work within the IETF: http://www.ietf.org/internet-drafts/draft-minei-diffserv-te-multi-class-02.txt. If this work is not adequate for your requirements, we would encourage you to work with its authors to produce a single standardized solution within the IETF. 15. In 9.5.4: An LSR that recognizes the Extended Classtype object and that receives a Path message which contains the Extended Classtype object but which does not contain a Label Request object or which does not have a session type of LSP_Tunnel_IPv4, must send a PathErr message towards the sender with the error code 'extended-classtype Error' and an error value of 'Unexpected Extended Classtype object'. These are defined below: Why do you define new parsing behavior for the absence of a Label Request object (by the way, you should say Generalized Label Request object, since this is GMPLS)? The absence of mandatory objects is already covered in RFC2205. 16. The error code defined in 9.5.4 is conformant with RFC 3936. You may wish to look at draft-swallow-rsvp-user-error-spec in case this gives you the ability to handle more detailed private error codes. Finally, we would like to refer you to draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01.txt and draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt for the latest state of discussions in CCAMP with respect to interworking MPLS and GMPLS networks. |