Link Bundling in MPLS Traffic Engineering (TE)
RFC 4201

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    mpls mailing list <mpls@lists.ietf.org>, 
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Protocol Action: 'Link Bundling in MPLS Traffic 
         Engineering' to Proposed Standard 

The IESG has approved the following document:

- 'Link Bundling in MPLS Traffic Engineering '
   <draft-ietf-mpls-bundle-07.txt> as a Proposed Standard

This document is the product of the Multiprotocol Label Switching Working 
Group. 

The IESG contact persons are Alex Zinin and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-07.txt

Technical Summary
 
   For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
   signaling in certain cases a combination of <link identifier, label>
   is not sufficient to unambiguously identify the appropriate resource
   used by a Label Switched Path (LSP).  Such cases are handled by using
   the link bundling construct which is described in this document.
   This document updates the interface identification TLVs defined in
   GMPLS Signaling Functional Description, [RFC3471].

Working Group Summary
 
   Version -04 of the document has been approved by the IESG before. However,
   while it was in the RFC-Editor queue, the WG identified a problem that was
   worth fixing before publication. The doc has been re-LC'ed and is back to
   the IESG for approval of the changes.
 
Protocol Quality
 
   The draft was reviewed for the IESG by Alex Zinin

RFC-Editor Note


Section 4. first para:

OLD:

   As defined in [GMPLS-ROUTING], a TE link is a logical construct that
   represents a way to group/map the information about certain physical
   resources (and their properties) that interconnect LSRs into the
   information that is used by Constrained SPF for the purpose of path
   computation, and by GMPLS signaling.

NEW:
   As defined in [GMPLS-ROUTING], a traffic engineering (TE) link is a
   logical construct that represents a way to group/map the information
   about certain physical resources (and their properties) that
   interconnect LSRs into the information that is used by Constrained
   SPF for the purpose of path computation, and by GMPLS signaling.

Section 4. second para:

OLD:
   As further stated in [GMPLS-ROUTING], depending on the nature of
   resources that form a particular TE link, for the purpose of GMPLS
   signaling in some cases a combination of <TE link identifier, label>
   is sufficient to unambiguously identify the appropriate resource used
   by an LSP. In other cases, a combination of <TE link identifier,
   label> is not sufficient.  Such cases are handled by using the link
   bundling construct which is described in this document.

NEW:
   As further stated in [GMPLS-ROUTING], depending on the nature of
   resources that form a particular TE link, for the purpose of GMPLS
   signaling in some cases a combination of <TE link identifier, label>
   is sufficient to unambiguously identify the appropriate resource used
   by an LSP. In other cases, a combination of <TE link identifier,
   label> is not sufficient.  Consider, for example, a TE link between
   a pair of SONET/SDH cross-connects, where this TE link is composed of
   several fibers.  In this case the label is a TDM time slot, and moreover,
   this time slot is significant only within a particular fiber. Thus, when
   signaling an LSP over such a TE link, one needs to specify not just
   the identity of the link, but also the identity of a particular
   fiber within that TE link, as well as a particular label (time
   slot) within that fiber. Such cases are handled by using the link
   bundling construct which is described in this document.

Last para:

OLD:
   The purpose of link bundling is to improve routing scalability by
   reducing the amount of information that has to be handled by OSPF
   and/or IS-IS. This reduction is accomplished by performing
   information aggregation/abstraction. As with any other information
   aggregation/abstraction, this results in losing some of the
   information. To limit the amount of losses one need to restrict the
                                                  ^^^^
   type of the information that can be aggregated/abstracted.

NEW
   The purpose of link bundling is to improve routing scalability by
   reducing the amount of information that has to be handled by OSPF
   and/or IS-IS. This reduction is accomplished by performing
   information aggregation/abstraction. As with any other information
   aggregation/abstraction, this results in losing some of the
   information. To limit the amount of losses one needs to restrict the
   type of the information that can be aggregated/abstracted.


Section 4.3. First para:

OLD:
   Typically, an LSP's ERO will identify the bundled link to be used for
   the LSP, but not the component link, since information about the
   bundled link is flooded, but information about the component links is
   not.  The identification of a component link in an ERO is outside the
   scope of this document.  When the bundled link is identified in an
   ERO or is dynamically identified, the choice of the component link
   for the LSP is a local matter between the two LSRs at each end of the
   bundled link.

NEW:
   Typically, an LSP's ERO will identify the bundled link to be used for
   the LSP, but not the component link, since information about the
   bundled link is flooded, but information about the component links is
   not.  While  Discovery of component link identities to be used in an ERO is
   outside the scope of the document, it is envisioned that such information
   may be provided via configuration or via future RRO extensions. When
   the bundled link is identified in an ERO or is dynamically identified,
   the choice of the component link for the LSP is a local matter between
   the two LSRs at each end of the bundled link.

Section 4.3. Signaling Considerations, Para 4:

OLD:
   [RFC3471] defines the Interface Identification TLV types. This
   document specifies that the TLV types 1, 2 and 3 SHOULD be used to
   indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs.
   Type 1 TLVs are used for IPv4 numbered component link identifiers.
   Type 2 TLVs are used for IPv6 numbered component link identifiers.
   Type 3 TLVs are used for unnumbered component link identifiers.  The
   Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
   Note, in Path and REQUEST messages, link identifiers MUST be
   specified from the sender's perspective.

NEW:
   [RFC3471] defines the Interface Identification type-length-value
   (TLV) types. This document specifies that the TLV types 1, 2 and 3
   SHOULD be used to indicate component links in IF_ID RSVP_HOP objects
   and IF_ID TLVs. Type 1 TLVs are used for IPv4 numbered component link
   identifiers. Type 2 TLVs are used for IPv6 numbered component link
   identifiers. Type 3 TLVs are used for unnumbered component link
   identifiers.  The Component Interface TLVs, TLV types 4 and 5,
   SHOULD NOT be used. Note, in Path and REQUEST messages, link
   identifiers MUST be specified from the sender's perspective.

Page 5, 3rd para:

OLD:
   In the special case where the same label is to be valid across all
   component links, two TLVs SHOULD used in an IF_ID RSVP_HOP object or
                             ^^^^^^^^^^^
   IF_ID TLV.  The first TLV indicates the TE link identifier of the
   bundle on which label allocation must be done.  The second TLV
   indicates a bundle scope label.  For TLV types 1 and 2 this is done
   by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for
   a type 1 TLV.  Per [RFC3471], for TLV types 3, 4 and 5, this is done
   by setting the Interface ID field to the special value 0xFFFFFFFF.
   Note that this special case applies to both unidirectional and
   bidirectional LSPs.

NEW:
   In the special case where the same label is to be valid across all
   component links, two TLVs SHOULD be used in an IF_ID RSVP_HOP object or
   IF_ID TLV.  The first TLV indicates the TE link identifier of the
   bundle on which label allocation must be done.  The second TLV
   indicates a bundle scope label.  For TLV types 1 and 2 this is done
   by using the special bit value of all ones (1), e.g., 0xFFFFFFFF for
   a type 1 TLV.  Per [RFC3471], for TLV types 3, 4 and 5, this is done
   by setting the Interface ID field to the special value 0xFFFFFFFF.
   Note that this special case applies to both unidirectional and
   bidirectional LSPs.