< draft-leroux-mpls-p2mp-te-autoleaf-01.txt   draft-leroux-mpls-p2mp-te-autoleaf-02.txt >
Network Working Group J.L. Le Roux (Editor) Network Working Group J.L. Le Roux (Editor)
France Telecom France Telecom
IETF Internet Draft J.P. Vasseur (Editor) IETF Internet Draft J.P. Vasseur (Editor)
Cisco System Inc. Cisco System Inc.
Proposed Status: Standard Track Seisho Yasukawa Proposed Status: Standard Track Seisho Yasukawa
Expires: January 2007 NTT Expires: April 2007 NTT
Martin Vigoureux
Alcatel
July 2006 October 2006
Routing extensions for discovery of P2MP TE LSP Leaf LSRs IGP Routing extensions for discovery of P2MP TE LSP Leaf LSRs
draft-leroux-mpls-p2mp-te-autoleaf-01.txt draft-leroux-mpls-p2mp-te-autoleaf-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 40 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The setup of a Point To MultiPoint (P2MP) Traffic Engineering Label In various situations, such as TV broadcasting with several regional
Switched Path (TE LSP) requires the head-end Label Switching Router sources, it is required to setup a series of Point-To-MultiPoint
(LSR) to be aware of all leaf LSRs. This may require the potentially (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) between a
cumbersome configuration of potentially a large number of leaf LSRs set of head-end Label Switching Routers (LSRs) and a group of leaf
on the P2MP TE LSP head-end LSR. Also leaf LSRs may want to LSRs referred to as a Leaf Group. Setting up such a series of P2MP TE
dynamically join or leave a P2MP TE LSP without requiring manual LSPs requires for the set of head-end LSRs to be aware of all leaf
configuration on the head-end LSR. This document specifies IGP LSRs, which may lead to the cumbersome configuration of a potentially
routing extensions for ISIS and OSPF so as to provide an automatic large number of leaf LSRs on each head-end LSRs. Furthermore leaf
discovery of the set of leaf LSRs members of a P2MP TE-LSP, also LSRs may want to dynamically join or leave a Leaf Group without
referred to as a P2MP TE Group, in order to automate the creation and requiring manual configuration on the head-end LSRs. This document
modification of such P2MP TE LSP. specifies IGP routing extensions for IS-IS and OSPF so as to provide
an automatic discovery of the set of leaf LSRs members of a Leaf
Group, in order to automate the creation and modification of a series
of P2MP TE-LSPs.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC-2119.
Table of Contents Table of Contents
1. Terminology.................................................2 1. Note........................................................3
2. Introduction................................................2 2. Terminology.................................................3
3. P2MP TE Group...............................................3 3. Introduction................................................3
3.1. Description.................................................3 4. Leaf Group..................................................4
3.2. Required Information........................................3 4.1. Description.................................................4
4. P2MP-TE-GROUP TLV formats...................................4 4.2. Required Information........................................4
4.1. OSPF P2MP-TE-GROUP TLV format...............................4 5. LEAF-GROUP TLV formats......................................4
4.2. IS-IS P2MP-TE-GROUP TLV format..............................5 5.1. OSPF LEAF-GROUP TLV format..................................4
5. Elements of procedure.......................................6 5.2. IS-IS LEAF-GROUP TLV format.................................6
5.1. OSPF........................................................6 6. Elements of procedure.......................................7
5.2. ISIS........................................................7 6.1. OSPF........................................................7
6. Backward compatibility......................................8 6.2. IS-IS.......................................................8
7. IANA Considerations.........................................8 7. Backward compatibility......................................9
7.1. OSPF........................................................8 8. IANA Considerations.........................................9
7.2. ISIS........................................................8 8.1. OSPF........................................................9
8. Security Considerations.....................................8 8.2. IS-IS.......................................................9
9. References..................................................8 9. Security Considerations....................................10
9.1. Normative references........................................8 10. References.................................................10
9.2. Informative References......................................9 10.1. Normative references.......................................10
10. Authors' Address...........................................10 10.2. Informative References.....................................11
11. Intellectual Property Statement............................10 11. Authors' Address...........................................11
12. Intellectual Property Statement............................12
1. Terminology 1. Note
This document uses terminologies defined in [RFC3031], [RFC3209], This document defines the concept of “Auto-leaf” along with the
[RFC4461], and [P2MP-RSVP-TE]. required IS-IS and OSPF extensions that may be described in separate
documents at a later stage.
2. Introduction 2. Terminology
[P2MP-RSVP] defines RSVP-TE extensions for setting up P2MP TE LSPs, This document uses terminologies defined in [RFC3031], [RFC3209],
with one ingress LSR and a set of one or more egress LSRs (leaves). [RFC4461], and [RSVP-P2MP-TE].
The setup of a P2MP TE LSP requires the ingress LSR to be aware of 3. Introduction
all leaf LSRs. In operational networks P2MP TE LSPs may comprise a
significant number of leaf LSRs and this may require cumbersome
configuration on the Ingress LSR, prone to misconfiguration.
Also Leaf LSRs may desire to dynamically join or leave a P2MP TE LSP. [RSVP-P2MP-TE] defines RSVP-TE extensions for setting up P2MP TE
LSPs, with one head-end LSR and a set of one or more leaf LSRs
(leaves).
Hence an automatic mechanism for discovering the leaf LSRs that want In various situations, such as for instance TV broadcasting with
to join or leave a P2MP TE LSP is desired. several non collocated sources, it is required to setup a series of
P2MP TE LSPs between a set of head-end LSRs and a common group of
leaf LSRs, that is a series of P2MP TE-LSPs with distinct head-end
LSRs and the same group of leaf LSRs. Such a group of leaf LSRs is
referred to as a "P2MP Leaf Group". The setup of such a P2MP LSP
series requires for each head-end LSRs to be aware of all leaf LSRs
in the P2MP Leaf Group. It is not uncommon for a P2MP Leaf Group to
contain a significant number of leaf LSRs, and there may be a
potentially large number of head-end LSRs. In such situations, this
requires cumbersome configuration of all leaf LSRs on each head-end
LSRs, prone to misconfiguration.
Furthermore, Leaf LSRs may desire to dynamically join or leave a P2MP
Leaf Group.
Hence an automatic mechanism allowing head-end LSRs to discover the
leaf LSRs willing to join or leave a Leaf Group would undoubtedly
ease the configuration task.
This document specifies IGP (OSPF and IS-IS) extensions so as to This document specifies IGP (OSPF and IS-IS) extensions so as to
automatically discover the leaf LSRs of a P2MP TE LSP also referred automatically discover the leaf LSRs of a Leaf Group. Note that the
to as a "P2MP TE Group". Note that the mechanism(s) needed for the mechanisms needed for the dynamic creation of P2MP TE LSPs and
dynamic creation of P2MP TE LSPs and dynamic Leaf addition/removal dynamic Leaf addition/removal (grafting/pruning), are implementation
(grafting/pruning), is implementation specific and outside the scope specific and outside the scope of this document. An implementation
of this document. An implementation should take special care of should take special care of implementing the appropriate dampening
implementing the appropriate dampening mechanisms to avoid any mechanisms to avoid any unacceptable impact on the IGP scalability.
unacceptable impact on the IGP scalability.
Routing extensions have been defined in [OSPF-CAP] and [ISIS-CAP] in Routing extensions have been defined in [OSPF-CAP] and [ISIS-CAP] in
order to advertise router capabilities. This document specifies IGP order to advertise router capabilities. This document specifies IGP
(OSPF and ISIS) P2MP TE Group TLVs allowing for the automatic (OSPF and ISIS) Leaf Group TLVs allowing an LSR to advertise its
discovery of a P2MP TE LSP leaf LSR, to be carried in the OSPF Router desire to join/leave one or more Leaf Group(s), to be carried in the
Information LSA [OSPF-CAP] and ISIS Router Capability TLV [ISIS-CAP]. OSPF Router Information LSA [OSPF-CAP] and IS-IS Router Capability
TLV [ISIS-CAP]. This allows the automatic creation and modification
of a series of P2MP TE LSPs without manual intervention.
3. P2MP TE Group 4. Leaf Group
3.1. Description 4.1. Description
A P2MP TE Group is defined as the set of leaf LSRs of a P2MP TE LSP. A Leaf Group is defined as a group of LSRs, which are leaves of a
Routing extensions are specified in this document allowing for series of one or more P2MP TE LSPs. Routing extensions are specified
dynamic discovery of the P2MP TE Group members. Procedures are also in this document allowing for dynamic discovery of the Leaf Group
specified for a member to join or leave a P2MP TE group. members. Procedures are also specified for a member to join or leave
a Leaf group.
An LSR may belong to multiple P2MP TE Group. An LSR may belong to multiple Leaf Groups.
3.2. Required Information 4.2. Required Information
This document specifies a P2MP-TE-GROUP TLV that indicates the set of This document specifies a LEAF-GROUP TLV that indicates the set of
P2MP TE Group(s) an LSR belongs to. For each P2MP TE group membership Leaf Group(s) an LSR belongs to. For each Leaf Group membership
announced by an LSR, the P2MP-TE-GROUP TLV advertises the following announced by an LSR, the LEAF-GROUP TLV is used to advertise a Leaf
information: Group number identifying the Leaf group the LSR belongs to.
- A P2MP TE group number identifying the P2MP TE group the LSR 5. LEAF-GROUP TLV formats
belongs to;
- A Leaf LSR address used by the Ingress LSR to signal a S2L sub-LSP
to the advertising LSR for this P2MP TE group.
4. P2MP-TE-GROUP TLV formats 5.1. OSPF LEAF-GROUP TLV format
4.1. OSPF P2MP-TE-GROUP TLV format The format of the OSPF LEAF-GROUP TLV is the same as the TLV format
used by the Traffic Engineering Extensions to OSPF [OSPF-TE]. That
is, the TLV is composed of 2 octets for the type, 2 octets specifying
the TLV length and a value field. The TLV is zero padded to four-
octet alignment; padding is not included in the length field (so a
three octet value would have a length of three, but the total size of
the TLV would be eight octets).
The format of the OSPF P2MP-TE-GROUP TLV is the same as the TLV The OSPF LEAF-GROUP TLV is used to advertise the desire of an LSR to
format used by the Traffic Engineering Extensions to OSPF [OSPF-TE]. join/leave a set of one or more Leaf Group(s).
That is, the TLV is composed of 2 octets for the type, 2 octets
specifying the TLV length and a value field. The TLV is padded to The OSPF IPv4 LEAF-GROUP TLV (advertised in an OSPFv2 Router
four-octet alignment; padding is not included in the length field (so Information LSA defined in [OSPF-CAP]) has the following format:
a three octet value would have a length of three, but the total size
of the TLV would be eight octets). The OSPF P2MP-TE-GROUP TLV is used
to advertise the desire of an LSR to join/leave a given P2MP TE LSP.
The OSPF IPv4 P2MP-TE-GROUP TLV (advertised in an OSPF router
information LSA defined in [OSPF-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 5) TYPE: To be assigned by IANA (Suggested Value: 5)
LENGTH: Variable LENGTH: Variable (>=8, multiple of 4)
VALUE: VALUE:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf LSR IPv4 address | | Leaf LSR IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // | Leaf Group Number 1 |
// //
| Leaf Group Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - IPv4 P2MP-TE-GROUP TLV format Figure 1 - IPv4 LEAF-GROUP TLV format
The OSPF IPv6 P2MP-TE-GROUP TLV (advertised in an OSPF router The OSPF IPv6 LEAF-GROUP TLV (advertised in an OSPFv3 Router
information LSA defined in [OSPF-CAP]) has the following format: Information LSA defined in [OSPF-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 6) TYPE: To be assigned by IANA (Suggested Value: 6)
LENGTH: Variable LENGTH: Variable (>= 20, multiple of 4)
VALUE: VALUE:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Leaf LSR IPv6 address | | Leaf LSR IPv6 address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // | Leaf Group Number 1 |
// //
| Leaf Group Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - IPv6 P2MP-TE-GROUP TLV format Figure 2 - IPv6 LEAF-GROUP TLV format
For each P2MP TE group announced by the LSR, the P2MP-TE-GROUP TLV The LEAF-GROUP TLV contains:
comprises:
- A P2MP TE group number that identifies the P2MP TE group. - A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L
- A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L sub-LSP destination address (defined in [RSVP-P2MP-TE]).
sub-LSP destination address for the corresponding P2MP TE group. - A set of one or more Leaf Group number(s), encoded with 32 bit
integers that identify the Leaf Group(s) the LSR belongs to.
4.2. IS-IS P2MP-TE-GROUP TLV format 5.2. IS-IS LEAF-GROUP TLV format
The IS-IS P2MP-TE-GROUP TLV is composed of 1 octet for the The IS-IS LEAF-GROUP TLV is composed of 1 octet for the type, 1 octet
type, 1 octet specifying the TLV length and a value field. The specifying the TLV length and a value field. The format of the LEAF-
format of the P2MP-TE-GROUP TLV is identical to the TLV format used GROUP TLV is identical to the TLV format used by the Traffic
by the Traffic Engineering Extensions for IS-IS [RFC3784]. Engineering Extensions for IS-IS [RFC3784].
The ISIS P2MP-TE-GROUP TLV is used to advertise the desire of an LSR The ISIS LEAF-GROUP TLV is used to advertise the desire of an LSR to
to join/leave a given P2MP TE LSP. join/leave a set of one or more Leaf Groups.
The ISIS IPv4 P2MP-TE-GROUP TLV (advertised in an IS-IS Router The ISIS IPv4 LEAF-GROUP TLV (advertised in an IS-IS Router
Capability TLV defined in [ISIS-CAP]) has the following format: Capability TLV defined in [ISIS-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 5) TYPE: To be assigned by IANA (Suggested Value: 5)
LENGTH: Variable LENGTH: Variable (>=8, multiple of 4)
VALUE: VALUE:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf LSR IPv4 address | | Leaf LSR IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // | Leaf Group Number 1 |
// //
| Leaf Group Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - IPv4 P2MP-TE-GROUP TLV format Figure 3 - IPv4 LEAF-GROUP TLV format
The ISIS IPv6 P2MP-TE-GROUP TLV (advertised in an OSPF router The ISIS IPv6 LEAF-GROUP TLV (advertised in an IS-IS router
information LSA defined in [OSPF-CAP]) has the following format: information LSA defined in [ISIS-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 6) TYPE: To be assigned by IANA (Suggested Value: 6)
LENGTH: Variable LENGTH: Variable
VALUE: VALUE:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Leaf LSR IPv6 address | | Leaf LSR IPv6 address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // | Leaf Group Number 1 |
// //
| Leaf Group Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - IPv6 P2MP-TE-GROUP TLV format Figure 4 - IPv6 LEAF-GROUP TLV format
For each P2MP TE group announced by the LSR, the ISIS P2MP-TE-GROUP
TLV comprises:
- A P2MP TE group number that identifies the P2MP TE group. The P2MP-LEAF-GROUP TLV comprises:
- A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L - A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L
sub-LSP destination address, for the corresponding P2MP TE group. sub-LSP destination address (defined in [RSVP-P2MP-TE]).
- A set of one or more Leaf Group number(s), encoded with 32
bit integers that identifies the Leaf Group(s) the LSR
belongs to.
5. Elements of procedure 6. Elements of procedure
5.1. OSPF 6.1. OSPF
The P2MP-TE-GROUP TLV is advertised, within an OSPFv2 Router The LEAF-GROUP TLV is carried within an OSPFv2 Router Information LSA
Information LSA (Opaque type of 4 and Opaque ID of 0) or OSPFv3 (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router information
Router information LSA (function code of 12) which are defined in LSA (function code of 12) that are defined in [OSPF-CAP]. As such,
[OSPF-CAP]. As such, elements of procedure are inherited from those elements of procedure are inherited from those defined in [OSPF-CAP].
defined in [OSPF-CAP].
The P2MP-TE-GROUP TLV is OPTIONAL and must at most appear once in an The LEAF-GROUP TLV is OPTIONAL. An OSPF Router Information LSA may
OSPF Router Information LSA. comprise zero one or more LEAF-GROUP TLVs. Several TLVs are used when
distinct destination addresses have to be used for distinct Leaf
Groups.
In OSPFv2 the flooding scope is controlled by the opaque LSA type (as In OSPFv2 the flooding scope is controlled by the opaque LSA type (as
defined in [RFC2370]) and in OSPFv3 by the S1/S2 bits (as defined in defined in [RFC2370]) and in OSPFv3 by the S1/S2 bits (as defined in
[OSPFv3]). The P2MP-TE-GROUP TLV flooding scope will depend on the [OSPFv3]).
P2MP TE LSP Ingress LSR and leaf LSRs location:
- If the Ingress LSR and generating LSR are located within the same The LEAF-GROUP TLV flooding scope will be determined according to the
area, the P2MP-TE-GROUP TLV MUST be generated within an OSPFV2 location of the head-end LSR(s) for the P2MP TE LSP related to the
type 10 Router Information LSA or an OSPFV3 Router Information LSA LEAF GROUP and the location of the Leaf LSR originating the LEAF-
with the S1 bit set and the S2 bit cleared. GROUP TLV:
- If the Ingress LSR and generating LSRs are located within distinct - If the head-end LSR(s) and leaf LSR originating the P2MP-LEAF-
areas, the P2MP-TE-GROUP TLV MUST be generated within an GROUP TLV are located within the same area, the LEAF-GROUP TLV
OSPFV2 type 11 Router Information LSA or an OSPFV3 Router MUST be generated within an OSPFV2 type 10 Router Information LSA
Information LSA with the S1 bit cleared and the S2 bit set. or an OSPFV3 Router Information LSA with the S1 bit set and the S2
bit cleared.
A router MUST originate a new OSPF router information LSA whenever - If the head-end LSR(s) and leaf LSRs originating the LEAF-GROUP
the content of the any of the advertised P2MP-TE-GROUP TLV changes or TLV are located within distinct areas the LEAF-GROUP TLV MUST be
whenever required by the regular OSPF procedure (LSA refresh (every generated within an OSPFV2 type 11 Router Information LSA or an
LSRefreshTime)). If an LSR desires to join or leave a particular P2MP OSPFV3 Router Information LSA with the S1 bit cleared and the S2
TE group, it MUST originate a new OSPF Router Information LSA bit set.
comprising the updated P2MP-TE-GROUP TLV. In the case of a join a new
entry will be added to the P2MP-TE-GROUP TLV; conversely if the LSR
leaves a P2MP TE group the corresponding entry will be removed from
the P2MP-TE-GROUP TLV. Note that both operations can be performed in
the context of a single refresh. An implementation SHOULD be able to
detect any change to a previously received P2MP-TE-GROUP TLV from a
specific LSR.
*Editorial note: Discussion on the number of groups and frequency of A router MUST originate a new OSPF Router Information LSA whenever
changes to be added* the content of the advertised LEAF-GROUP TLV changes or whenever
required by the regular OSPF procedure (LSA refresh (every
LSRefreshTime)). If an LSR desires to join or leave a particular Leaf
group, it MUST originate a new OSPF Router Information LSA containing
the updated LEAF-GROUP TLV. In the case of a join a new entry will be
added to the LEAF-GROUP TLV; conversely, if the LSR leaves a Leaf
Group the corresponding entry will be removed from the LEAF-GROUP
TLV. Note that both operations can be performed in the context of a
single refresh. An implementation SHOULD be able to detect any change
to a previously received LEAF-GROUP TLV from a specific LSR.
5.2. ISIS A P2MP LSP is likely to aggregate a large number of multicast
channels and hence the number of Leaf Groups an LSR belongs to is
expected to be very small, typically less than 10. Otherwise, in the
case of a large number of Leaf Groups care should be given to the
relevance of using an IGP-based discovery mechanism.
The P2MP-TE-GROUP TLV is advertised, within the IS-IS Router Moreover, as spelt out in [RFC4461], the dynamics of the P2MP LSP is
CAPABILITY TLV defined in [ISIS-CAP]. As such, elements of procedure likely to be relatively small. A working figure for an established
are inherited from those defined in [ISIS-CAP]. P2MP TE LSP is less than 10% churn per day; that is, a relatively
slow rate of churn. Nevertheless appropriate rate limiting and
dampening mechanisms SHOULD be implemented so as to avoid any
unacceptable impact on IGP scalability. The dampening and rate
limiting algorithms in use are outside of the scope of this document.
The P2MP-TE-GROUP TLV is OPTIONAL and must at most appear once in an 6.2. IS-IS
ISIS Router CAPABILITY TLV.
The P2MP-TE-GROUP TLV flooding scope will depend on the P2MP TE LSP The LEAF-GROUP TLV is carried within the IS-IS Router CAPABILITY TLV
Ingress LSR and leaf LSRs location: that is defined in [ISIS-CAP]. As such, elements of procedure are
inherited from those defined in [ISIS-CAP].
- If the Ingress LSR and generating LSR are located within a single The LEAF-GROUP TLV is OPTIONAL. An IS-IS Router CAPABILITY TLV may
IS-IS area/level, the P2MP-TE-GROUP TLV MUST not be leaked across comprise zero one or more LEAF-GROUP TLVs. Several TVLs are used when
IS-IS level/area and the S flag of the Router CAPABILITY TLV MUST distinct destination addresses have to be used for distinct Leaf
be cleared. Groups.
- If the Ingress LSR and generating LSRs are located within distinct The LEAF-GROUP TLV flooding scope will depend on the head-end
IS-IS area/level, the P2MP-TE-GROUP TLV MUST be leaked across IS- LSR(s) and generating LSR location:
IS level/area and the S flag of the Router CAPABILITY TLV MUST be
set. - If the head-end LSR(s) and generating LSR are located within a
single IS-IS area/level, the LEAF-GROUP TLV MUST not be leaked
across IS-IS level/area and the S flag of the Router CAPABILITY
TLV MUST be cleared.
- If the head-end LSR(s) and generating LSR are located within
distinct IS-IS area/level, the LEAF-GROUP TLV MUST be leaked
across IS-IS level/area and the S flag of the Router CAPABILITY
TLV MUST be set.
An IS-IS router MUST originate a new IS-IS LSP whenever the content An IS-IS router MUST originate a new IS-IS LSP whenever the content
of the any of the advertised P2MP-TE-GROUP TLV changes or whenever of the advertised LEAF-GROUP TLV changes or whenever required by the
required by the regular IS-IS procedure (LSP refresh). If an LSR regular IS-IS procedure (LSP refresh). If an LSR desires to join or
desires to join or leave a particular P2MP TE group, it MUST leave a particular Leaf Group, it MUST originate a new IS-IS LSP
originate a new LSP comprising the updated P2MP-TE-GROUP TLV. In the containing the updated LEAF-GROUP TLV. In the case of a join a new
case of a join a new entry will be added to the P2MP-TE-GROUP TLV; entry will be added to the LEAF-GROUP TLV; conversely, if the LSR
conversely if the LSR leaves a P2MP TE group the corresponding entry leaves a Leaf Group the corresponding entry will be removed from the
will be removed from the P2MP-TE-GROUP TLV. Note that both operations LEAF-GROUP TLV. Note that both operations can be performed in the
can be performed in the context of a single refresh. An context of a single refresh. An implementation SHOULD be able to
implementation SHOULD be able to detect any change to a previously detect any change to a previously received LEAF-GROUP TLV from a
received P2MP-TE-GROUP TLV from a specific LSR. specific LSR.
*Editorial note: Discussion on the number of groups and frequency of A P2MP LSP is likely to aggregate a large number of multicast
changes to be added* channels and hence the number of Leaf groups an LSR belongs to is
expected to be very small, typically less than 10. Otherwise, in the
case of a large number of Leaf Groups care should be given to the
relevance of using an IGP-based discovery mechanism.
6. Backward compatibility Moreover, as spelt out in [RFC4461], the dynamics of the P2MP LSP is
likely to be relatively small. A working figure for an established
P2MP TE LSP is less than 10% churn per day; that is, a relatively
slow rate of churn. Nevertheless appropriate rate limiting and
dampening mechanisms SHOULD be implemented so as to avoid any
unacceptable impact on IGP scalability. The dampening and rate
limiting algorithms in use are outside of the scope of this document.
The P2MP-TE-GROUP TLVs defined in this document do not introduce any 7. Backward compatibility
The LEAF-GROUP TLVs defined in this document do not introduce any
interoperability issue. interoperability issue.
For OSPF, a router not supporting the P2MP-TE-GROUP TLV MUST just For OSPF, a router not supporting the LEAF-GROUP TLV MUST just
silently ignore the TLV as specified in [OSPF-CAP]. silently ignore the TLV as specified in [OSPF-CAP].
For IS-IS a router not supporting the P2MP-TE-GROUP TLV MUST just For IS-IS a router not supporting the LEAF-GROUP TLV MUST just
silently ignore the TLV as specified in [IS-IS-CAP]. silently ignore the TLV as specified in [IS-IS-CAP].
7. IANA Considerations 8. IANA Considerations
7.1. OSPF 8.1. OSPF
IANA is in charge of the assignment of TLV code points for the Router IANA is in charge of the assignment of TLV code points for the Router
Information LSA defined in [OSPF-CAP]. Information LSA defined in [OSPF-CAP].
IANA will assign a new codepoint for the P2MP-TE-GROUP TLV defined in IANA will assign a new codepoint for the LEAF-GROUP TLVs defined in
this document and carried within the Router Information LSA. this document and carried within the Router Information LSA.
IPv4 P2MP-TE-GROUP TLV (suggested value=5) IPv4 LEAF-GROUP TLV (suggested value=5)
IPv6 P2MP-TE-GROUP TLV (suggested value=6) IPv6 LEAF-GROUP TLV (suggested value=6)
7.2. ISIS 8.2. IS-IS
IANA is in charge of the assignment of TLV code points for the IS-IS IANA is in charge of the assignment of TLV code points for the IS-IS
Router CAPABILITY TLV defined in [ISIS-CAP]. Router CAPABILITY TLV defined in [ISIS-CAP].
IANA will assign a new codepoint for the P2MP-TE-GROUP TLV defined in IANA will assign a new codepoint for the LEAF-GROUP TLVs defined in
this document and carried within the IS-IS Router CAPABILITY TLV. this document and carried within the IS-IS Router CAPABILITY TLV.
IPv4 P2MP-TE-GROUP TLV (suggested value=5) IPv4 LEAF-GROUP TLV (suggested value=5)
IPv6 P2MP-TE-GROUP TLV (suggested value=6)
8. Security Considerations
No new security issues are raised in this document. IPv6 LEAF-GROUP TLV (suggested value=6)
9. References 9. Security Considerations
9.1. Normative references This document specifies the content of the LEAF GROUP TLV in IS-IS
and OSPF, to be used for automating the setup of P2MP TE-LSPs. As
this TLV is not used for SPF computation or normal routing, the
extensions specified here have no direct effect on IP routing.
Tampering with this TLV may have an effect on the configuration of
P2MP TE-LSP. Mechanisms defined to secure IS-IS Link State PDUs
[ISIS-HMAC], OSPF LSAs [OSPF-SIG], and their TLVs, can be used to
secure this TLV as well. DoS attacks that would consist of
advertising a considerable number of Leaf Groups would not lead to
the generation of the corresponding P2MP TE LSPs since this would
also require for other LSRs acting as head-end to be also configured
with matching Leaf Groups.
[RFC] Bradner, S., "Key words for use in RFCs to indicate 10. References
requirements levels", RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10.1. Normative references
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004. 3667, February 2004.
[BCP79] Bradner, S., "Intellectual Property Rights in IETF [BCP79] Bradner, S., "Intellectual Property Rights in IETF
Technology", RFC 3979, March 2005. Technology", RFC 3979, March 2005.
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPF-v3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", [OSPF-v3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
skipping to change at page 9, line 38 skipping to change at page 11, line 8
[IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", RFC 3784, June 2004. Engineering", RFC 3784, June 2004.
[OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur,
J.P., "Extensions to OSPF for advertising Optional Router J.P., "Extensions to OSPF for advertising Optional Router
Capabilities", draft-ietf-ospf-cap, work in progress. Capabilities", draft-ietf-ospf-cap, work in progress.
[IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising
router information", draft-ietf-isis-caps, work in progress. router information", draft-ietf-isis-caps, work in progress.
[RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to [RSVP-P2MP-TE] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions
RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- to RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te-
p2mp, work in progress. p2mp, work in progress.
9.2. Informative References 10.2. Informative References
[P2MP-REQ] Yasukawa, S., et. al., "Signaling Requirements for Point [RFC4461] Yasukawa, S., et. al., "Signaling Requirements for Point to
to Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006. Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006.
10. Authors' Address 11. Authors' Addresses
Jean-Louis Le Roux (Editor) Jean-Louis Le Roux (Editor)
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
Jean-Philippe Vasseur (Editor) JP Vasseur (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585, Musashino-Shi, Tokyo 180-8585,
Japan Japan
11. Intellectual Property Statement Martin Vigoureux
Alcatel
Route de Nozay, 91461 Marcoussis cedex, France
Phone: +33 (0)1 69 63 18 52
Email: martin.vigoureux@alcatel.fr
12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 90 change blocks. 
222 lines changed or deleted 285 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/