--- 1/draft-ietf-ccamp-isis-interas-te-extension-01.txt 2008-04-14 13:12:12.000000000 +0200 +++ 2/draft-ietf-ccamp-isis-interas-te-extension-02.txt 2008-04-14 13:12:12.000000000 +0200 @@ -1,20 +1,21 @@ + Network working group M. Chen Internet Draft Renhai Zhang -Expires: October 2008 Huawei Technologies Co.,Ltd -Category: Standards Track Xiaodong Duan - China Mobile - April 10, 2008 +Category: Standards Track Huawei Technologies Co.,Ltd +Created: April 14, 2008 Xiaodong Duan +Expires: October 14, 2008 China Mobile ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - draft-ietf-ccamp-isis-interas-te-extension-01.txt + + draft-ietf-ccamp-isis-interas-te-extension-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering @@ -25,21 +26,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on October 10, 2008. + This Internet-Draft will expire on October 14, 2008. Abstract This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. @@ -47,49 +48,49 @@ proposed or defined in this document. 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]. Table of Contents - 1. Introduction.................................................2 - 2. Problem Statement............................................3 + 1. Introduction.................................................3 + 2. Problem Statement............................................4 2.1. A Note on Non-Objectives................................4 - 2.2. Per-Domain Path Determination...........................4 + 2.2. Per-Domain Path Determination...........................5 2.3. Backward Recursive Path Computation.....................6 3. Extensions to ISIS-TE........................................7 3.1. Inter-AS Reachability TLV...............................8 3.2. TE Router ID............................................9 3.3. Sub-TLV Detail.........................................10 3.3.1. Remote AS Number Sub-TLV..........................10 3.3.2. IPv4 Remote ASBR ID Sub-TLV.......................10 3.3.3. IPv6 Remote ASBR ID Sub-TLV.......................11 3.3.4. IPv4 TE Router ID sub-TLV.........................12 - 3.3.5. IPv6 TE Router ID sub-TLV.........................13 + 3.3.5. IPv6 TE Router ID sub-TLV.........................12 4. Procedure for Inter-AS TE Links.............................13 4.1. Origin of Proxied TE Information.......................14 - 5. Security Considerations.....................................15 + 5. Security Considerations.....................................14 6. IANA Considerations.........................................15 6.1. Inter-AS Reachability TLV..............................15 - 6.2. Sub-TLVs for the Inter-AS Reachability TLV.............16 + 6.2. Sub-TLVs for the Inter-AS Reachability TLV.............15 6.3. Sub-TLVs for the IS-IS Router Capability TLV...........16 7. Acknowledgments.............................................16 - 8. References..................................................17 - 8.1. Normative References...................................17 - 8.2. Informative References.................................17 - Authors' Addresses.............................................18 + 8. References..................................................16 + 8.1. Normative References...................................16 + 8.2. Informative References.................................16 + Authors' Addresses.............................................17 Intellectual Property Statement................................18 - Disclaimer of Validity.........................................19 - Copyright Statement............................................19 + Disclaimer of Validity.........................................18 + Copyright Statement............................................18 1. Introduction [ISIS-TE] defines extensions to the ISIS protocol [ISIS] to support intra-area Traffic Engineering (TE). The extensions provide a way of encoding the TE information for TE-enabled links within the network (TE links) and flooding this information within an area. The Extended IS Reachability TLV and Traffic Engineering Router ID TLV, which are defined in [ISIS-TE], are used to carry such TE information. The Extended IS Reachability TLV has several nested sub-TLVs which @@ -178,21 +180,22 @@ document and [L1VPN-OSPF-AD]. 2.2. Per-Domain Path Determination In the per-domain method of determining an inter-AS path for an MPLS- TE LSP, when an LSR that is an entry-point to an AS receives a Path message from an upstream AS with an ERO containing a next hop that is an AS number, it needs to find which LSRs (ASBRs) within the local AS are connected to the downstream AS so that it can compute a TE LSP segment across the local AS to one of those LSRs and forward the PATH - message to it and hence into the next AS. See Figure 1 for an example: + message to it and hence into the next AS. See Figure 1 for an + example: R1------R3----R5-----R7------R9-----R11 | | \ | / | | | \ | ---- | | | \ | / | R2------R4----R6 --R8------R10----R12 : : <-- AS1 -->:<---- AS2 --->:<--- AS3 ---> Figure 1: Inter-AS Reference Model @@ -557,53 +560,54 @@ IPv6 TE Router ID sub-TLV MUST be included if the ASBR has an IPv6 TE Router ID. If the ASBR does not have an IPv6 TE Router ID, the IPv4 TE Router sub-TLV MUST be included instead. An IPv4 TE Router ID sub- TLV and IPv6 TE Router ID sub-TLV MAY both be present in an IS-IS Router Capability TLV. 4. Procedure for Inter-AS TE Links When TE is enabled on an inter-AS link and the link is up, the ASBR SHOULD advertise this link using the normal procedures for ISIS-TE - [ISIS-TE]. When either the link is down or TE is disabled on the link, - the ASBR SHOULD withdraw the advertisement. When there are changes to - the TE parameters for the link (for example, when the available - bandwidth changes) the ASBR SHOULD re-advertise the link, but the - ASBR MUST take precautions against excessive re-advertisements. + [ISIS-TE]. When either the link is down or TE is disabled on the + link, the ASBR SHOULD withdraw the advertisement. When there are + changes to the TE parameters for the link (for example, when the + available bandwidth changes) the ASBR SHOULD re-advertise the link, + but the ASBR MUST take precautions against excessive + re-advertisements. - Hellos MUST NOT be exchanged over the inter-AS link, and consequently, - an ISIS adjacency MUST NOT be formed. + Hellos MUST NOT be exchanged over the inter-AS link, and + consequently, an ISIS adjacency MUST NOT be formed. The information advertised comes from the ASBR's knowledge of the TE capabilities of the link, the ASBR's knowledge of the current status and usage of the link, and configuration at the ASBR of the remote AS number and remote ASBR TE Router ID. Legacy routers receiving an advertisement for an inter-AS TE link are able to ignore it because they do not know the new TLV and sub-TLVs that are defined in Section 3 in this document. They will continue to flood the LSP, but will not attempt to use the information received. In the current operation of ISIS TE the LSRs at each end of a TE link emit LSAs describing the link. The databases in the LSRs then have two entries (one locally generated, the other from the peer) that describe the different 'directions' of the link. This enables CSPF to do a two-way check on the link when performing path computation and eliminate it from consideration unless both directions of the link satisfy the required constraints. - In the case we are considering here (i.e., of a TE link to another AS) - there is, by definition, no IGP peering and hence no bi-directional - TE link information. In order for the CSPF route computation entity - to include the link as a candidate path, we have to find a way to get - LSAs describing its (bidirectional) TE properties into the TE - database. + In the case we are considering here (i.e., of a TE link to another + AS) there is, by definition, no IGP peering and hence no + bi-directional TE link information. In order for the CSPF route + computation entity to include the link as a candidate path, we have + to find a way to get LSAs describing its (bidirectional) TE + properties into the TE database. This is achieved by the ASBR advertising, internally to its AS, information about both directions of the TE link to the next AS. The ASBR will normally generate a LSA describing its own side of a link; here we have it 'proxy' for the ASBR at the edge of the other AS and generate an additional LSA that describes that devices 'view' of the link. Only some essential TE information for the link needs to be advertised; i.e., the Interface Address, the Remote AS number and the @@ -725,48 +730,48 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. - [ISIS-TE-V3] Harrison, J., Berger, J., and Bartlett, M., "IPv6 - Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te, - {work in progress}. - [ISIS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising router information", RFC 4971, July 2007. 8.2. Informative References [INTER-AS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering Requirements", RFC4216, November 2005. [PD-PATH] Ayyangar, A., Vasseur, JP., and Zhang, R., "A Per-domain path computation method for establishing Inter-domain", RFC 5152, February 2008. - [BRPC] JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux, "A Backward - Recursive PCE-based Computation (BRPC) procedure to compute - shortest inter-domain Traffic Engineering Label Switched - Paths ", draft-ietf-pce-brpc, (work in progress) + [BRPC] JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux, "A + Backward Recursive PCE-based Computation (BRPC) procedure + to compute shortest inter-domain Traffic Engineering Label + Switched Paths", draft-ietf-pce-brpc, (work in progress). [PCE] Farrel, A., Vasseur, JP., and Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC4655, August 2006. [ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. + [ISIS-TE-V3] Harrison, J., Berger, J., and Bartlett, M., "IPv6 + Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te, + (work in progress). + [GMPLS-TE] K.Kompella and Y.Rekhter, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching", RFC 4205, October 2005. [L1VPN-OSPF-AD] Bryskin, I., and Berger, L., "OSPF Based L1VPN Auto- Discovery", draft-ietf-l1vpn-ospf-auto-discovery, (work in progress). [BGP] Rekhter, Li, Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC4271, January 2006