Protocol Action: 'Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet 
   Provider Backbone Traffic Engineering (PBB-TE) '
   <draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt> as a Proposed Standard


This document is the product of the Common Control and Measurement Plane Working Group. 

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt

Technical Summary

   This specification is complementary to the GMPLS Ethernet Label
   Switching Architecture and Framework [RFC5828] and describes the 
   technology specific aspects of GMPLS control for Provider Backbone 
   Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary 
   GMPLS extensions and mechanisms are described to establish Ethernet 
   PBB-TE point to point (P2P) and point to multipoint (P2MP)
   connections. This document supports, but does not modify, the
   standard IEEE data plane.

Working Group Summary

   Nothing of note.

Document Quality

   There are no known implementations, but it is expected that several
   vendors plan to implement.

Personnel

   Deborah Brungard ([e-mail]) is the Document Shepherd.
   Adrian Farrel ([e-mail]) is the Responsible AD.

RFC Editor Note

Section 4.1

OLD
   Note, PBB-TE is designed to be bidirectional and symmetrically routed
   just like Ethernet. That is, complete and proper functionality of
   Ethernet protocols is only guaranteed for bidirectional Eth-LSPs.  In
   the following we discuss the establishment of bidirectional Eth-LSPs.

   Note however that it is also possible to use RSVP-TE to configure
   unidirectional ESPs, if the UPSTREAM_LABEL is not included in the
   PATH message.     To initiate a bidirectional Eth-LSP, the initiator
   of the PATH message MUST use the procedures outlined in [RFC3473]
   with the following specifics:
NEW
   PBB-TE is designed to be bidirectional and symmetrically routed just
   like Ethernet. That is, complete and proper functionality of Ethernet
   protocols is only guaranteed for bidirectional Eth-LSPs. In this
   section we discuss the establishment of bidirectional Eth-LSPs.

   Note, however, that it is also possible to use RSVP-TE to configure
   unidirectional ESPs, if the UPSTREAM_LABEL is not included in the
   PATH message. 
   
   To initiate a bidirectional Eth-LSP, the initiator of the PATH
   message MUST use the procedures outlined in [RFC3473] with the
   following specifics:
END

---

Section 4.1.1

s/Eth LSP/Eth-LSP/

---

Section 5.1.2

OLD
   The destination bridge after receiving the PATH message has to
   allocate a VID, which together with its MAC address will constitute
   the PBB-TE Ethernet Label. Depending on the size of the allocated
   VLAN range and the number of Eth-LSPs terminated on a particular
   bridge, it is possible that the available VIDs are exhausted and
   hence no PBB-TE Ethernet Label can be allocated. In this case the
   destination bridge SHOULD generate a PathErr message with error code:
   Routing problem (24) and error value: MPLS Label allocation failure
   (9).
NEW
   The destination bridge after receiving the PATH message has to
   assign a VID, which together with its MAC address will constitute
   the PBB-TE Ethernet Label.  An existing VID may be reused 
   when Shared forwarding is used or when there are no path conflicts 
   otherwise the bridge has to allocate a VID.   
   Depending on the size of the allocated VLAN range and the number of
   Eth-LSPs terminated on a particular bridge, it is possible that the
   available VIDs are exhausted and hence no PBB-TE Ethernet Label can
   be allocated. In this case the destination bridge SHOULD generate a
   PathErr message with error code: Routing problem (24) and error
   value: MPLS Label allocation failure (9).
END

---

Section 5.2

OLD
   IEEE defines a set of reserved MAC addresses Table 8-1 [IEEE 802.1Q]
   that have special meaning, processing and follow specific forwarding
   rules.
NEW
   IEEE defines a set of reserved MAC addresses from 01-80-C2-00-00-00
   to 01-80-C2-00-00-0F as explained in [IEEE 802.1Q] that have special
   meaning, processing, and follow specific forwarding rules.
END

---

Section 6 Acronym expansions

UNI - User-to-Network Interface
NNI - Network-to-Network Interface
DOS - Denial of Service

---

Section 6

OLD
   For a more comprehensive discussion on GMPLS security please see the
   Security Framework for MPLS and GMPLS Networks[RFC5920].
   Cryptography can be used to protect against many attacks described in
   [RFC5920].  One option for protecting "transport" Ethernet is the use
   of 802.1AE Media Access Control Security, [MACSEC] which provides
   encryption and authentication."
NEW
   Where control plane communications are point-to-point over links that
   employ 802.1AE Media Access Control Security [MACSEC], it may 
   reasonably determined that no further security measures are used. In
   other cases, it is appropriate to use control plane security where it
   is deemed necessary to secure the signaling messages. GMPLS signaling
   security measures are described in [RFC3471] and [RFC3473], and
   inherit security techniques applicable to RSVP-TE as described in
   [RFC3209] and [RFC2205]. For a fuller overview of GMPLS security
   techniques see [RFC5920].
END

---

Section 7
DELETE
     - Assign a new globally defined error value: "PBB-TE Ethernet Label
       VID allocation failure" (suggested value: 35?)  under the
       "Routing problem" (24) error code in the RSVP Parameters / Error
       Codes and Globally-Defined Error Value Sub-Codes registry.
END

---

Section 7
OLD
     - Assign a new type from the Attributes TLV Space in the RSVP-TE
       Parameters registry (suggested value 2) for the Service ID TLV
       that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type
       = 1) [RFC5420].
NEW
     - Assign a new type from the Attributes TLV Space in the RSVP-TE
       Parameters registry (suggested value 2) for the Service ID TLV
       that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type
       = 1) [RFC5420]. Please reocrd this new type as follows:
         Name:                               I-SID Association TLV
         Allowed on LSP_ATTRIBUTES           Yes
         Allowed on LSP_REQUIRED_ATTRIBUTES  No
END

---

Section 8.1

ADD
   [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
        Specification", RFC 2205, September 1997.

---

Section 8.1

   [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of
      End-to-End Generalized Multi-Protocol Label Switching
      (GMPLS)-based Recovery", RFC 4871, May 2007.

s/4871/4872/

---

IANA Note

  IANA: Please note the two RFC Editor note changes to Section 7.