GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4972

Network Working Group JP. Vasseur, Ed. Request for Comments: 4972 Cisco Systems, Inc Category: Standards Track JL. Leroux, Ed.

                                                        France Telecom
                                                           S. Yasukawa
                                                                   NTT
                                                            S. Previdi
                                                             P. Psenak
                                                    Cisco Systems, Inc
                                                             P. Mabbey
                                                               Comcast
                                                             July 2007
     Routing Extensions for Discovery of Multiprotocol (MPLS)
 Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 The setup of a full mesh of Multi-Protocol Label Switching (MPLS)
 Traffic Engineering (TE) Label Switched Paths (LSP) among a set of
 Label Switch Routers (LSR) is a common deployment scenario of MPLS
 Traffic Engineering either for bandwidth optimization, bandwidth
 guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment
 may require the configuration of a potentially large number of TE
 LSPs (on the order of the square of the number of LSRs).  This
 document specifies Interior Gateway Protocol (IGP) routing extensions
 for Intermediate System-to-Intermediate System (IS-IS) and Open
 Shortest Path First (OSPF) so as to provide an automatic discovery of
 the set of LSRs members of a mesh in order to automate the creation
 of such mesh of TE LSPs.

Vasseur, et al. Standards Track [Page 1] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

Table of Contents

 1. Introduction ....................................................2
 2. Definitions .....................................................3
    2.1. Conventions Used in This Document ..........................4
 3. Description of a TE Mesh-Group ..................................4
 4. TE-MESH-GROUP TLV Formats .......................................4
    4.1. OSPF TE-MESH-GROUP TLV Format ..............................4
    4.2. IS-IS TE-MESH-GROUP Sub-TLV Format .........................7
 5. Elements of Procedure ...........................................9
    5.1. OSPF .......................................................9
    5.2. IS-IS .....................................................10
 6. Backward Compatibility .........................................11
 7. IANA Considerations ............................................11
    7.1. OSPF ......................................................11
    7.2. IS-IS .....................................................11
 8. Security Considerations ........................................12
 9. Acknowledgements ...............................................12
 10. References ....................................................12
    10.1. Normative References .....................................12
    10.2. Informative References ...................................13

1. Introduction

 There are two well-known approaches in deploying MPLS Traffic
 Engineering:
 (1) The so-called "strategic" approach that consists of setting up a
 full mesh of TE LSPs between a set of LSRs.
 (2) The so-called "tactical" approach, where a set of TE LSPs are
 provisioned on well-identified "hot spots" in order to alleviate a
 congestion resulting, for instance, from an unexpected traffic growth
 in some parts of the network.
 The setup of a full mesh of TE LSPs among a set of LSRs is a common
 deployment scenario of MPLS Traffic Engineering either for bandwidth
 optimization, bandwidth guarantees, or fast rerouting with MPLS Fast
 Reroute.  Setting up a full mesh of TE LSPs between N LSRs requires
 the configuration of a potentially large number of TE LSPs (O(N^2)).
 Furthermore, the addition of any new LSR in the mesh requires the
 configuration of N additional TE LSPs on the new LSR and one new TE
 LSP on every LSR of the existing mesh destined to this new LSR, which
 gives a total of 2*N TE LSPs to be configured.  Such an operation is
 not only time consuming but also risky (prone to misconfiguration)
 for Service Providers.  Hence, an automatic mechanism for setting up
 TE LSPs meshes is desirable and requires the ability to automatically
 discover the set of LSRs that belong to the mesh.  This document

Vasseur, et al. Standards Track [Page 2] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

 specifies routing extensions so as to automatically discover the
 members of a mesh, also referred to as a "TE mesh-group".  Note that
 the mechanism(s) needed for the dynamic creation of TE LSPs is
 implementation specific and outside the scope of this document.
 Routing extensions have been defined in [RFC4970] and [RFC4971] in
 order to advertise router capabilities.  This document specifies IGP
 (OSPF and IS-IS) TE Mesh Group (Type Length Value) TLVs allowing for
 the automatic discovery of a TE mesh-group members, to be carried in
 the OSPF Router Information (Link State Advertisement) LSA [RFC4970]
 and IS-IS Router Capability TLV [RFC4971].  The routing extensions
 specified in this document provide the ability to signal multiple TE
 mesh groups.  An LSR may belong to more than one TE mesh-group(s).
 There are relatively tight real-time constraints on the operation of
 IGPs (such as OSPF and IS-IS).  For this reason, some care needs to
 be applied when proposing to carry additional information in an IGP.
 The information described in this document is both relatively small
 in total volume (compared with other information already carried in
 IGPs), and also relatively stable (i.e., changes are based on
 configuration changes, but not on dynamic events within the network,
 or on dynamic triggers, such as the leaking of information from other
 routing protocols or routing protocol instances).

2. Definitions

 Terminology used in this document
 IGP: Interior Gateway Protocol
 IGP Area: OSPF area or IS-IS level
 IS-IS: Intermediate System-to-Intermediate System (IS-IS)
 LSR: Label Switch Router
 OSPF: Open Shortest Path First
 OSPF LSA: OSPF Link State Advertisement
 TE LSP: Traffic Engineering Label Switched Path
 TE LSP head-end: head/source of the TE LSP
 TE LSP tail-end: tail/destination of the TE LSP.
 TLV: Type Length Value

Vasseur, et al. Standards Track [Page 3] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

2.1. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

3. Description of a TE Mesh-Group

 A TE mesh-group is defined as a group of LSRs that are connected by a
 full mesh of TE LSPs.  Routing extensions are specified in this
 document, allowing for dynamic discovery of the TE mesh-group
 members.  Procedures are also specified for a member to join and
 leave a TE mesh-group.  For each TE mesh-group membership announced
 by an LSR, the following information is advertised:
  1. A mesh-group number identifying the TE mesh-group that the LSR

belongs to,

  1. A tail-end address (used as the TE LSP Tail-end address by other

LSRs belonging to the same mesh-group),

  1. A tail-end name: a display string that is allocated to the tail-

end used to ease the TE-LSP naming.

4. TE-MESH-GROUP TLV Formats

4.1. OSPF TE-MESH-GROUP TLV Format

 The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to
 join/leave a given TE mesh-group.  No sub-TLV is currently defined
 for the TE-MESH-GROUP TLV.
 The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information
 LSA defined in [RFC4970]) has the following format:
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                            Value                            //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 1 - OSPF TE-MESH-GROUP TLV format

Vasseur, et al. Standards Track [Page 4] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

 Where
    Type: identifies the TLV type
    Length: the length of the value field in octets
 The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV
 format used by the Traffic Engineering Extensions to OSPF
 (see[RFC3630]).  The TLV is padded to a 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).  Nested TLVs are also 32-bit aligned.  Unrecognized types
 are ignored.  All types between 32768 and 65535 are reserved for
 vendor-specific extensions.  All other undefined type codes are
 reserved for future assignment by IANA.
 The OSPF TE-MESH-GROUP TLV format for IPv4 (Figure 2) and IPv6
 (Figure 3) is as follows:
 TYPE: 3
 LENGTH: Variable
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      mesh-group-number 1                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Tail-end IPv4 address 1                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |               Tail-end name 1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                               //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      mesh-group-number n                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Tail-end IPv4 address n                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |               Tail-end name n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)

Vasseur, et al. Standards Track [Page 5] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

 TYPE: 4
 LENGTH: Variable
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    mesh-group-number 1                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                   Tail-end IPv6 address 1                     |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |             Tail-end name 1                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                               //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    mesh-group-number n                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                   Tail-end IPv6 address n                     |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |             Tail-end name n                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address)
 The OSPF TE-MESH-GROUP TLV may contain one or more mesh-group
 entries, where each entry corresponds to a TE mesh-group and is made
 of the following fields:
  1. A mesh-group-number that identifies the mesh-group number.
  1. A Tail-end address: an IPv4 or IPv6 IP address to be used as a

tail-end TE LSP address by other LSRs belonging to the same mesh-

    group.
  1. Name length field: An integer, expressed in octets, that indicates

the length of the Tail-end name before padding.

  1. A Tail-end name: A display string that is allocated to the Tail-

end. The field is of variable length field and is used to

    facilitate the TE LSP identification.

Vasseur, et al. Standards Track [Page 6] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

4.2. IS-IS TE-MESH-GROUP Sub-TLV Format

 The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR
 to join/leave a given TE mesh-group.  No sub-TLV is currently defined
 for the TE-MESH-GROUP sub-TLV.
 The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY
 TLV defined in [RFC4971]) is composed of 1 octet for the type, 1
 octet specifying the TLV length and a value field.  The format of the
 TE-MESH-GROUP sub-TLV is identical to the TLV format used by the
 Traffic Engineering Extensions for IS-IS [RFC3784].
 The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (Figure 4) and IPv6
 (Figure 5) is as follows:
 TYPE: 3
 LENGTH: Variable
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     mesh-group-number 1                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Tail-end IPv4 address  1                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |             Tail-end name 1                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                               //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     mesh-group-number n                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Tail-end IPv4 address n                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |             Tail-end name n                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address)

Vasseur, et al. Standards Track [Page 7] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

 TYPE: 4
 LENGTH: Variable
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      mesh-group-number 1                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                    Tail-end IPv6 address 1                    |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |            Tail-end name 1                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                               //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      mesh-group-number n                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                    Tail-end IPv6 address n                    |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Name length  |            Tail-end name n                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Figure 5 - IS-IS TE-MESH-GROUP sub-TLV format (IPv6 Address)
 The IS-IS TE-MESH-GROUP sub-TLV may contain one or more mesh-group
 entries where each entry correspond to a TE mesh-group and is made of
 the following fields:
  1. A mesh-group-number that identifies the mesh-group number.
  1. A Tail-end address: an IPv4 or IPv6 IP address to be used as a

tail-end TE LSP address by other LSRs belonging to the same mesh-

    group.
  1. Name length field: An integer, expressed in octets, that indicates

the length of the Tail-end name before padding.

  1. A Tail-end name: A display string that is allocated to the Tail-

end. The field is of variable length and is used to facilitate

    the TE LSP identification.

Vasseur, et al. Standards Track [Page 8] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

5. Elements of Procedure

 The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing
 Information LSA and the IS-IS TE-MESH-GROUP sub-TLV is carried within
 the IS-IS Router capability TLV.  As such, elements of procedure are
 inherited from those defined in [RFC4970] and [RFC4971] for OSPF and
 IS-IS respectively.  Specifically, a router MUST originate a new
 LSA/LSP whenever the content of this information changes, or whenever
 required by regular routing procedure (e.g., updates).
 The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one
 of each of the IPv4 instances or the IPv6 instance.  If either the
 IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within
 the OSPF Router Information LSA, only the first instance is
 processed, subsequent TLV(s) SHOULD be silently ignored.  Similarly,
 if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs
 more than once within the IS-IS Router capability TLV, only the first
 instance is processed, subsequent TLV(s) SHOULD be silently ignored.

5.1. OSPF

 The TE-MESH-GROUP TLV is advertised within an OSPF Router Information
 opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 [RFC2328]
 and within a new LSA (Router Information LSA) for OSPFv3 [RFC2740].
 The Router Information LSAs for OSPFv2 and OSPFv3 are defined in
 [RFC4970].
 A router MUST originate a new OSPF router information LSA whenever
 the content of any of the advertised TLV changes or whenever required
 by the regular OSPF procedure (LSA update (every LSRefreshTime)).  If
 an LSR desires to join or leave a particular TE mesh group, it MUST
 originate a new OSPF Router Information LSA comprising the updated
 TE-MESH-GROUP TLV.  In the case of a join, a new entry will be added
 to the TE-MESH-GROUP TLV; conversely, if the LSR leaves, a mesh-group
 the corresponding entry will be removed from the TE-MESH-GROUP TLV.
 Note that both operations can be performed in the context of a single
 LSA update.  An implementation SHOULD be able to detect any change to
 a previously received TE-MESH-GROUP TLV from a specific LSR.
 As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the
 flooding scope of the Router Information LSA is determined by the LSA
 Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3.
 For OSPFv2 Router Information opaque LSA:
  1. Link-local scope: type 9;
  1. Area-local scope: type 10;

Vasseur, et al. Standards Track [Page 9] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

  1. Routing-domain scope: type 11. In this case, the flooding scope

is equivalent to the Type 5 LSA flooding scope.

 For OSPFv3 Router Information LSA:
  1. Link-local scope: OSPFv3 Router Information LSA with the S1 and S2

bits cleared;

  1. Area-local scope: OSPFv3 Router Information LSA with the S1 bit

set and the S2 bit cleared;

  1. Routing-domain scope: OSPFv3 Router Information LSA with S1 bit

cleared and the S2 bit set.

 A router may generate multiple OSPF Router Information LSAs with
 different flooding scopes.
 The TE-MESH-GROUP TLV may be advertised within an Area-local or
 Routing-domain scope Router Information LSA, depending on the MPLS TE
 mesh group profile:
  1. If the MPLS TE mesh-group is contained within a single area (all

the LSRs of the mesh-group are contained within a single area),

    the TE-MESH-GROUP TLV MUST be generated within an Area-local
    Router Information LSA.
  1. If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh-

group TLV MUST be generated within a Routing-domain scope router

    information LSA.

5.2. IS-IS

 The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router
 CAPABILITY TLV defined in [RFC4971].  An IS-IS router MUST originate
 a new IS-IS LSP whenever the content of any of the advertised sub-TLV
 changes or whenever required by regular IS-IS procedure (LSP
 updates).  If an LSR desires to join or leave a particular TE mesh
 group, it MUST originate a new LSP comprising the refreshed IS-IS
 Router capability TLV comprising the updated TE-MESH-GROUP sub-TLV.
 In the case of a join, a new entry will be added to the TE-MESH-GROUP
 sub-TLV; conversely, if the LSR leaves a mesh-group, the
 corresponding entry will be deleted from the TE-MESH-GROUP sub-TLV.
 Note that both operations can be performed in the context of a single
 update.  An implementation SHOULD be able to detect any change to a
 previously received TE-MESH-GROUP sub-TLV from a specific LSR.
 If the flooding scope of a TE-MESH-GROUP sub-TLV is limited to an
 IS-IS level/area, the sub-TLV MUST not be leaked across level/area

Vasseur, et al. Standards Track [Page 10] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

 and the S flag of the Router CAPABILITY TLV MUST be cleared.
 Conversely, if the flooding scope of a TE-MESH-GROUP sub-TLV is the
 entire routing domain, the TLV MUST be leaked across IS-IS
 levels/areas, and the S flag of the Router CAPABILITY TLV MUST be
 set.  In both cases, the flooding rules specified in [RFC4971] apply.
 As specified in [RFC4971], a router may generate multiple IS-IS
 Router CAPABILITY TLVs within an IS-IS LSP with different flooding
 scopes.

6. Backward Compatibility

 The TE-MESH-GROUP TLVs defined in this document do not introduce any
 interoperability issue.  For OSPF, a router not supporting the TE-
 MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in
 [RFC2370].  For an IS-IS, a router not supporting the TE-MESH-GROUP
 sub-TLV SHOULD just silently ignore the sub-TLV.

7. IANA Considerations

7.1. OSPF

 The registry for the Router Information LSA is defined in [RFC4970].
 IANA assigned a new OSPF TLV code-point for the TE-MESH-GROUP TLVs
 carried within the Router Information LSA.
 Value      Sub-TLV                   References
 -----     --------                   ----------
   3    TE-MESH-GROUP TLV (IPv4)      RFC 4972 (this doc)
   4    TE-MESH-GROUP TLV (IPv6)      RFC 4972 (this doc)

7.2. IS-IS

 The registry for the Router Capability TLV is defined in [RFC4971].
 IANA assigned a new IS-IS sub-TLV code-point for the TE-MESH-GROUP
 sub-TLVs carried within the IS-IS Router Capability TLV.
 Value      Sub-TLV                  References
 -----      --------                 ----------
   3    TE-MESH-GROUP TLV (IPv4)     RFC 4972 (this doc)
   4    TE-MESH-GROUP TLV (IPv6)     RFC 4972 (this doc)

Vasseur, et al. Standards Track [Page 11] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

8. Security Considerations

 The function described in this document does not create any new
 security issues for the OSPF and IS-IS protocols.  Security
 considerations are covered in [RFC2328] and [RFC2740] for the base
 OSPF protocol and in [RFC1195] for IS-IS.  It must be noted that the
 advertisement of "fake" TE Mesh Group membership(s) by a mis-
 configured or malicious LSR Y would not have any major impact on the
 network (other than overloading the IGP), such as triggering the set
 up of new MPLS TE LSP: indeed, for a new TE LSP originated by another
 LSR X destined to LSR Y to be set up, the same TE Mesh group
 membership must be configured on both LSRs.  Thus such fake
 advertisement could not amplify any Denial of Service (DoS) attack.

9. Acknowledgements

 We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec,
 Dave Ward, Les Ginsberg, Stephen Nadas, Acee Lindem, Dimitri
 Papadimitriou, and Lakshminath Dondeti for their useful comments.

10. References

10.1. Normative References

 [RFC4971]  Vasseur, J-P., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
            "Intermediate System to Intermediate System (IS-IS)
            Extensions for Advertising Router Information", RFC 4971,
            July 2007.
 [RFC4970]  Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
            S. Shaffer, "Extensions to OSPF for Advertising Optional
            Router Capabilities", RFC 4970, July 2007.
 [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
            dual environments", RFC 1195, December 1990.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 [RFC2370]  Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
            1998.
 [RFC2740]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
            2740, December 1999.

Vasseur, et al. Standards Track [Page 12] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

10.2. Informative References

 [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
            (TE) Extensions to OSPF Version 2", RFC 3630, September
            2003.
 [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
            System (IS-IS) Extensions for Traffic Engineering (TE)",
            RFC 3784, June 2004.

Authors' Addresses

 JP Vasseur (editor)
 Cisco Systems, Inc
 1414 Massachusetts Avenue
 Boxborough, MA  01719
 USA
 EMail: jpv@cisco.com
 JL Le Roux (editor)
 France Telecom
 2, Avenue Pierre-Marzin
 Lanion,   22307
 FRANCE
 EMail: jeanlouis.leroux@orange-ftgroup.com
 Seisho Yasukawa
 NTT
 3-1, Otemachi 2-Chome Chiyoda-ku
 Tokyo,   100-8116
 JAPAN
 EMail: s.yasukawa@hco.ntt.co.jp
 Stefano Previdi
 Cisco Systems, Inc
 Via Del Serafico 200
 Roma,   00142
 Italy
 EMail: sprevidi@cisco.com

Vasseur, et al. Standards Track [Page 13] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

 Peter Psenak
 Cisco Systems
 Mlynske Nivy 43
 821 09
 Bratislava
 Slovakia
 EMail: ppsenak@cisco.com
 Paul Mabbey
 Comcast Cable
 4100 E. Dry Creek Rd
 Centennial, CO 80122
 USA
 EMail: Paul_Mabey@cable.comcast.com

Vasseur, et al. Standards Track [Page 14] RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 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
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Vasseur, et al. Standards Track [Page 15]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4972.txt · Last modified: 2007/07/31 00:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki