Liaison to ITU-T SG15

[George Swallow <swallow@cisco.com>]

Liaison Statement

Submission 
   Date:      2006-09-13

From:         Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; 
                 loa@pi.se)
              Scott Bradner  (IETF Liaison to ITU-T, sob@harvard.edu)
              Deborah Brungard  (IETF CCAMP WG Chair, dbrungard@att.com)
              Stewart Bryant (IETF PWE3 WG Chair, stbryant@cisco.com)
              Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair,    
                adrian@olddog.co.uk)
              Danny McPherson  (IETF PWE3 WG Chair, danny@arbor.net)
              George Swallow (IETF MPLS WG Chair, swallow@cisco.com)
                
To:           ITU-T Study Group 15; Greg Jones  (greg.jones@itu.int)

CC:           IESG  (iesg@ietf.org)
              IAB  (iab@ietf.org)
              Steve Trowbridge  (sjtrowbridge@lucent.com)
              Malcolm Betts  (betts01@nortel.com)
              Yoichi Maeda  (maeda@ansl.ntt.co.jp)
              Ghani Abbas  (ghani.abbas@marconi.com)
              Houlin Zhao  (houlin.zhao@itu.int)
              CCAMP mailing list (ccamp@ops.ietf.org)
              MPLS mailing list (mpls@lists.ietf.org)
              PWE3 mailing list (pwe3@ietf.org)


Re:           T-MPLS use of the MPLS Ethertypes

Response  
    Contact:  George Swallow  

Technical 
    Contact:  George Swallow

Purpose:      For action

Deadline:     2006-10-13


     We would like to thank you for your response to our liaison.  We
     feel that through the liaison activity and the Ottawa meeting we
     have entered into a productive and useful dialogue.  We are
     particularly pleased by your positive reaction to most of our
     concerns.

     We do, however, once again, request documentation of the problem
     that T-MPLS solves.  We feel that this documentation is
     fundamental to a proper review of the T-MPLS architecture,
     protocol requirements, and any future solutions, and we advise
     the ITU-T not to present any T-MPLS Recommendations for consent
     until work on a T-MPLS problem statement is well
     advanced. Further, a full reference diagram of the interfaces and
     services of the T-MPLS network would be most useful.  We
     understand that the direct adaptation of an IP/MPLS client over a
     T-MPLS server is still at a very preliminary stage.  However,
     some understanding of the client/server relationship is necessary
     in order to adequately evaluate architectural decisions currently
     being made in G.8110.1.

     The most immediate concern is the proposed use of the MPLS
     Ethertypes.  In your liaison to the MFA Forum dated 19-23 June
     2006 you say,

     First we would like to call your attention to the fact that we
     are in the process of modifying the semantics of the two
     Ethertypes used by MPLS.  Currently their designations are "MPLS
     Unicast" (8847) and "MPLS Multicast" (8848).  The new semantics
     will be "Downstream Assigned" (8847) and "Upstream Assigned"
     (8848)".  On a practical level, they will still be used for
     Unicast and Multicast respectively, however the change has been
     made to clarify which Label Switch Router (LSR) controls each
     label space.

     Each of these label spaces is shared by all MPLS applications.
     Each space is managed by a label-manager which is responsible for
     label allocation and reclamation.  When a packet is received at
     the downstream LSR with Ethertype 8847 it is looked up in a table
     managed by the downstream router.  Conversely when a packet is
     received at the downstream LSR with Ethertype 8848 it is looked
     up in a table managed by the upstream router.

     In your liaison to the MFA Forum dated 19-23 June 2006 you say,

        T-MPLS is intended to be a separate layer network with respect
        to MPLS. However, T- MPLS will use the same data-link protocol
        ID (e.g. EtherType), frame format and forwarding semantics for
        as those defined for MPLS frames.  T-MPLS and MPLS cannot
        coexist on the same "interface" (for example they could not
        coexist on a single Ethernet VLAN, however they could be
        multiplexed on to a common Ethernet PHY using separate VLANs).

     On the face of it, this statement implies that MPLS and T-MPLS
     are two different things, but that you wish to identify them both
     using the same Ethertype.  The Ethertype is the primary means for
     multiplexing and distinguishing protocols over Ethernet.  The
     Ethertype identifies the protocol entity that will receive a
     packet at the layer above.  VLANs on the other hand are primarily
     intended as a service level interface, allowing multiple virtual
     LANs over a single bridged domain.  .

     If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is
     in fact a separate layer network, then it should be identified by
     its own Ethertype(s), Clear and unambiguous identification is in
     the best interest of all involved.  In particular, if T- MPLS is
     being architected in such a way that would prevent it from
     acquiring labels by interacting with a shared label manager, then
     separate Ethertypes would guarantee that there is no confusion as
     to which label spaces belong to T-MPLS.

     Note further that if T-MPLS is being architected in such a way
     that it can (or could) interact with a shared label manager and
     could co-exist over the same interface sharing the MPLS label
     spaces with other MPLS applications, then we would welcome use of
     the MPLS Ethertypes.

     We believe that a decision to use the MPLS Ethertypes to point to
     a label space other than as defined by the MPLS RFCs to be
     architecturally unsound and ultimately will prove to be limiting
     to the deployment options available in networks which employ both
     MPLS and T-MPLS.

     Sincerely,

        Loa Andersson 
        Scott Bradner
        Deborah Brungard
        Stewart Bryant
        Adrian Farrel 
        Danny McPherson
        George Swallow



========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719