[mpls] Fw: liaison response to to IETF ccamp WG on MFA Forum MPLS CNI

["Adrian Farrel" <[e-mail]>]

Hi,

The MPLS WG may be interested in a liaison received by CCAMP on the 
definition of a CNI by the MFA.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, September 01, 2007 10:22 PM
Subject: Fw: liaison response to to IETF ccamp WG on MFA Forum MPLS CNI


> Hi,
>
> We have received the attached liaison from the MFA.
> I expect it will be posted on the IETF web site in due course. In the mean 
> time, you can find it at www.olddog.co.uk/ccamp.htm
>
> The liaison does not ask for any action from us, but we may want to review 
> the new specification and comment on it.
>
> Thanks,
> Adrian
> ----- Original Message ----- 
> From: "J. Rao Cherukuri" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
> <[e-mail]>
> Cc: "David Sinicrope (RL/TNT)" <[e-mail]>; 
> <[e-mail]>; "BOCCI Matthew" 
> <[e-mail]>; "Ross Callon" <[e-mail]>; 
> <[e-mail]>; <[e-mail]>
> Sent: Friday, August 31, 2007 8:34 PM
> Subject: liaison response to to IETF ccamp WG on MFA Forum MPLS CNI
>
>
> Hi Adrian, Deborah,
>
> Thank you and the CCAMP WG for providing such thorough and valuable
> comments.  We have reviewed and incorporated many of them into the CNI
> document.  There are a few that we have not incorporated for various
> reasons.  We have provided the rationale for these decisions inline
> below.
>
> Please let us know if you have any questions or concerns.
>
> Best Regards,
> David  Sinicrope  AD Working Group Chair
>
> Rao Cherukuri TC Chair
>
> ***************************************
>
> 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.
>
> MFAF> At the time of development of our specification draft-andersson
> was not adopted by IETF.  Also, the Multi Class specification wasn't in
> a state where we could refer to it.  Consequently, we chose to use the
> vendor private TLV to expedite completion of our document.   In
> subsequent revisions of the CNI we will consider following
> draft-andersson and obtaining a standard Multi Class TLV.
>
> 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 its 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?
> MFAF> Review is completed and document is in "last call".
>
> 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.
>
> MFAF> We have gone through the document and reflected your suggestions
> in the text.
>
> 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.
> MFAF> We have reflected this suggestion in the text of section 1.2.
>
> 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.
> MFAF> To facilitate use of bi-direction LSPs and to leverage existing
> implementations of the standard.
> We have reflected this rationale in the text of section 1.2.
>
> 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?
> MFAF>We assume that the core is PSC only.  The CNI is implemented at the
> edge of the network.
> Details of the core network beyond what is stated in section 1.3 are
> beyond the scope of the CNI.
>
> 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
> MFAF> In section 1.3 we state that the core has support for a minimum
> set of GMPLS capabilities.
> e.g., bidirectional LSP support, traffic engineering QoS capabilities.
>
> 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".
>
> MFAF> We have reflected this suggestion in the text.  See the Acronyms
> section.
>
> 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?
>
> MFAF> At our last meeting in Chicago we decided to allow the use of the
> IF_ID_RSVP_HOP as an option.  See section 7.2.
>
> 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.
>
> MFAF> We corrected the text to address this issue in section 7.3.
> Also see the changes in section 9.1.2.
>
> 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?
>
> MFAF>This is assumed and although how it is done is beyond the
> scope of the specification, section 7.4.1 now states what is expected of
> the network.
>
> 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.
>
> MFAF> We still do not mandate ERO because there was no agreement
> within the MFAF TC to mandate it.  See changes made in 9.1.2.
>
> 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).
>
> MFAF> We reflected this in section 9.1.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.
>
> MFAF>We reflected this in section 9.4.
>
> 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
> <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.
>
> MFAF>We removed all references to PSB, and all reference to "at every
> hop".
> This better aligns with our scope of not specifying the network
> internals.
> See section 9.5.3.
>
> 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.
>
> MFAF> We removed the reference to "the absence of (Generalized) Label
> Request object".
> This implies that if the Generalized Label Request object is missing,
> the relevant procedures of RFC 2205 will
> be performed.
>
> 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.
>
> MFAF> In our specifications we are limited to referring only to
> documents
> that have been progressed to the RFC editor queue and beyond.  We will
> certainly
> consider reference to draft-swallow-rsvp-user-error-spec in future
> revisions of the CNI.
>
> 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.
>
> MFAF> Thanks for pointing out these documents.  We will consider these
> should our work
> scope be expanded to include details of the core network and MPLS and
> GMPLS interworking.
>
> Attachment(s):
>
>
>
>
>
>
>
> 




_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls