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

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

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):