The IESG has approved the following document:
- 'Link Bundling in MPLS Traffic Engineering '
<draft-ietf-mpls-bundle-06.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 Bill Fenner.
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.
_______________________________________________
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
