Protocol Action: Signalling Unnumbered Links in RSVP-TE to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




The IESG has approved the Internet-Draft Signalling Unnumbered 
Links in RSVP-TE <draft-ietf-mpls-rsvp-unnum-08.txt> as a Proposed 
Standard.  This document is the product of the Multiprotocol Label 
Switching Working Group.  The IESG contact persons are Bert Wijnen and 
Scott Bradner.
 
 
Technical Summary

Supporting MPLS TE over unnumbered links (i.e., links that do not have 
IP addresses) involves two components: (a) the ability to carry (TE)
information about unnumbered links in IGP TE extensions (ISIS or OSPF), 
and (b) the ability to specify unnumbered links in MPLS TE signalling. 
The former is covered in other documents. The focus of this document 
is on the latter.

Current signalling used by MPLS TE doesn't provide support for 
unnumbered links because the current signalling doesn't provide a way 
to indicate an unnumbered link in its Explicit Route and Record Route 
Objects. This document defines simple procedures and extensions that 
allow RSVP-TE signalling [GMPLS-RSVP] to be used with unnumbered links.


Working Group Summary

The MPLS working group supported publication of this document.

Protocol Quality

This document was reviewed for the IESG by Scott Bradner.


RFC Editor Note:

In section 5 replace

       An unnumbered link has to be a point-to-point link. An LSR at each
       end of an unnumbered link assigns an identifier to that link. This
       identifier is a non-zero 32-bit number that is unique within the
       scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP
       modules on an LSR must agree on the identifiers.

 with

       An unnumbered link has to be a point-to-point link. An LSR at
       each end of an unnumbered link assigns an identifier to that
       link. This identifier is a non-zero 32-bit number that is unique
       within the scope of the LSR that assigns it. If one is using
       OSPF or ISIS as the IGP in support of traffic engineering, then
       the IS-IS and/or OSPF and RSVP modules on an LSR must agree on
       the identifiers.

 In section 5 replace

       In the context of this document the term "Router ID" refers to the
       "Router Address" as defined in [OSPF-TE], or "Traffic Engineering
       Router ID" as defined in [ISIS-TE].

 with

       In the context of this document the term "Router ID" means a
       stable IP address of an LSR that is always reachable if there
       is any connectivity to the LSR. This is typically implemented
       as a "loopback address"; the key attribute is that the address
       does not become unusable if an interface on the LSR is down.
       In some case this value will need to be configured. If one is
       using OSPF or ISIS as the IGP in support of traffic engineering,
       then it is RECOMMENDED to set the Router ID to the "Router
       Address" as defined in [OSPF-TE], or "Traffic Engineering Router
       ID" as defined in [ISIS-TE].


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux