draft-ietf-lsr-isis-area-proxy-03.txt | draft-ietf-lsr-isis-area-proxy-04.txt | |||
---|---|---|---|---|
Internet Engineering Task Force T. Li | Internet Engineering Task Force T. Li | |||
Internet-Draft S. Chen | Internet-Draft S. Chen | |||
Intended status: Experimental V. Ilangovan | Intended status: Experimental V. Ilangovan | |||
Expires: February 6, 2021 Arista Networks | Expires: March 6, 2021 Arista Networks | |||
G. Mishra | G. Mishra | |||
Verizon Inc. | Verizon Inc. | |||
August 5, 2020 | September 2, 2020 | |||
Area Proxy for IS-IS | Area Proxy for IS-IS | |||
draft-ietf-lsr-isis-area-proxy-03 | draft-ietf-lsr-isis-area-proxy-04 | |||
Abstract | Abstract | |||
Link state routing protocols have hierarchical abstraction already | Link state routing protocols have hierarchical abstraction already | |||
built into them. However, when lower levels are used for transit, | built into them. However, when lower levels are used for transit, | |||
they must expose their internal topologies to each other, leading to | they must expose their internal topologies to each other, leading to | |||
scale issues. | scale issues. | |||
To avoid this, this document discusses extensions to the IS-IS | To avoid this, this document discusses extensions to the IS-IS | |||
routing protocol that would allow level 1 areas to provide transit, | routing protocol that would allow level 1 areas to provide transit, | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on February 6, 2021. | This Internet-Draft will expire on March 6, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 24 ¶ | skipping to change at page 2, line 24 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
2. Area Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Area Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6 | 3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 6 | 3.1. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 7 | 3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 7 | |||
3.3. Responsibilities with respect to the Proxy LSP . . . . . 8 | ||||
4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 8 | 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 8 | |||
4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 8 | 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 8 | |||
4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.3. Distributing Area Proxy Information . . . . . . . . . . . 8 | 4.3. Distributing Area Proxy Information . . . . . . . . . . . 8 | |||
4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8 | 4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8 | |||
4.3.2. The Area SID Sub-TLV . . . . . . . . . . . . . . . . 9 | 4.3.2. The Area SID Sub-TLV . . . . . . . . . . . . . . . . 9 | |||
4.4. Proxy LSP Generation . . . . . . . . . . . . . . . . . . 10 | 4.4. Proxy LSP Generation . . . . . . . . . . . . . . . . . . 11 | |||
4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 11 | 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 11 | |||
4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 11 | 4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 11 | |||
4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 11 | 4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 11 | |||
4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 11 | 4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 11 | |||
4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 11 | 4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 12 | |||
4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 12 | 4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 12 | |||
4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 12 | 4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 12 | |||
4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 13 | 4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 13 | |||
4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 13 | 4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 13 | |||
4.4.10. The SID/Label Binding and The Multi-Topology | 4.4.10. The SID/Label Binding and The Multi-Topology | |||
SID/Label Binding SID TLV . . . . . . . . . . . . . . 13 | SID/Label Binding SID TLV . . . . . . . . . . . . . . 14 | |||
4.4.11. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 13 | 4.4.11. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 14 | |||
4.4.12. Traffic Engineering Information . . . . . . . . . . . 14 | 4.4.12. Traffic Engineering Information . . . . . . . . . . . 14 | |||
4.4.13. The Area SID . . . . . . . . . . . . . . . . . . . . 14 | 4.4.13. The Area SID . . . . . . . . . . . . . . . . . . . . 14 | |||
5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 14 | 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 15 | |||
5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 14 | 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 15 | |||
5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15 | 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15 | |||
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 18 | 9.2. Informative References . . . . . . . . . . . . . . . . . 18 | |||
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
1. Introduction | 1. Introduction | |||
The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- | The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- | |||
level hierarchy of abstraction. The fundamental unit of abstraction | level hierarchy of abstraction. The fundamental unit of abstraction | |||
is the 'area', which is a (hopefully) connected set of systems | is the 'area', which is a (hopefully) connected set of systems | |||
running IS-IS at the same level. Level 1, the lowest level, is | running IS-IS at the same level. Level 1, the lowest level, is | |||
abstracted by routers that participate in both Level 1 and Level 2, | abstracted by routers that participate in both Level 1 and Level 2, | |||
and they inject area information into Level 2. Level 2 systems | and they inject area information into Level 2. Level 2 systems | |||
seeking to access Level 1, use this abstraction to compute the | seeking to access Level 1, use this abstraction to compute the | |||
skipping to change at page 5, line 5 ¶ | skipping to change at page 5, line 5 ¶ | |||
There are four classes of routers that we need to be concerned with | There are four classes of routers that we need to be concerned with | |||
in this discussion: | in this discussion: | |||
Inside Router A router within the Inside Area that runs Level 1 and | Inside Router A router within the Inside Area that runs Level 1 and | |||
Level 2 IS-IS. A router is recognized as an Inside Router by the | Level 2 IS-IS. A router is recognized as an Inside Router by the | |||
existence of its LSP in the Level 1 LSDB. | existence of its LSP in the Level 1 LSDB. | |||
Area Leader The Area Leader is an Inside Router that is elected to | Area Leader The Area Leader is an Inside Router that is elected to | |||
represent the Level 1 area by injecting the Proxy LSP into the | represent the Level 1 area by injecting the Proxy LSP into the | |||
Level 2 LSDB. There may be multiple candidates for Area Leader, | Level 2 LSDB. There may be multiple candidates for Area Leader, | |||
but only one is elected at a given time. | but only one is elected at a given time. Any Inisde Router can be | |||
Area Leader. | ||||
Inside Edge Router An Inside Edge Router is an Inside Area Router | Inside Edge Router An Inside Edge Router is an Inside Area Router | |||
that has at least one Level 2 interface outside of the Inside | that has at least one Level 2 interface outside of the Inside | |||
Area. An interface on an Inside Edge Router that is connected to | Area. An interface on an Inside Edge Router that is connected to | |||
an Outside Edge Router is an Area Proxy Boundary. | an Outside Edge Router is an Area Proxy Boundary. | |||
Outside Edge Router An Outside Edge Router is a Level 2 router that | Outside Edge Router An Outside Edge Router is a Level 2 router that | |||
is outside of the Inside Area that has an adjacency with an Inside | is outside of the Inside Area that has an adjacency with an Inside | |||
Edge Router. | Edge Router. | |||
skipping to change at page 5, line 50 ¶ | skipping to change at page 6, line 4 ¶ | |||
Identifier. This allows all Outside Routers to use the Proxy LSP in | Identifier. This allows all Outside Routers to use the Proxy LSP in | |||
their SPF computations without seeing the full topology of the Inside | their SPF computations without seeing the full topology of the Inside | |||
Area. | Area. | |||
Area Proxy functionality assumes that all circuits on Inside Routers | Area Proxy functionality assumes that all circuits on Inside Routers | |||
are either Level 1-2 circuits within the Inside Area, or Level 2 | are either Level 1-2 circuits within the Inside Area, or Level 2 | |||
circuits between Outside Edge Routers and Inside Edge Routers. | circuits between Outside Edge Routers and Inside Edge Routers. | |||
Area Proxy Boundary multi-access circuits (i.e. Ethernets in LAN | Area Proxy Boundary multi-access circuits (i.e. Ethernets in LAN | |||
mode) with multiple Inside Edge Routers on them are not supported. | mode) with multiple Inside Edge Routers on them are not supported. | |||
The Inside Edge Router on any boundary LAN MUST NOT flood Inside | The Inside Edge Router on any boundary LAN MUST NOT flood Inside | |||
Router LSPs on this link. Boundary LANs SHOULD NOT be enabled for | Router LSPs on this link. Boundary LANs SHOULD NOT be enabled for | |||
Level 1. An Inside Edge Router may be elected the DIS for a Boundary | Level 1. An Inside Edge Router may be elected the DIS for a Boundary | |||
LAN. In this case using the Area Proxy System Id as the basis for | LAN. In this case using the Area Proxy System Id as the basis for | |||
the LAN pseudonode identifier could create a collision, so the | the LAN pseudonode identifier could create a collision, so the | |||
Insider Edge Router SHOULD compose the pseudonode identifier using | Insider Edge Router SHOULD compose the pseudonode identifier using | |||
its native system identifier. | its native system identifier. This choice of pseudonode identifier | |||
may confuse neighbors with an extremely strict implementation, in | ||||
which case the Inside Edge Router may be configured with priority 0, | ||||
causing an Outside Router to be elected DIS. | ||||
2.1. Segment Routing | 2.1. Segment Routing | |||
If the Inside Area supports Segment Routing [RFC8402], then all | If the Inside Area supports Segment Routing [RFC8402], then all | |||
Inside Nodes MUST advertise an SR Global Block (SRGB). The first | Inside Nodes MUST advertise an SR Global Block (SRGB). The first | |||
value of the SRGB advertised by all Inside Nodes MUST start at the | value of the SRGB advertised by all Inside Nodes MUST start at the | |||
same value. The range advertised for the area will be the minimum of | same value. The range advertised for the area will be the minimum of | |||
all Inside Nodes. | all Inside Nodes. | |||
To support Segment Routing, the Area Leader will take the global SID | To support Segment Routing, the Area Leader will take the global SID | |||
skipping to change at page 7, line 21 ¶ | skipping to change at page 7, line 24 ¶ | |||
A node advertises the Area Proxy TLV in its L2 LSP. The Area Proxy | A node advertises the Area Proxy TLV in its L2 LSP. The Area Proxy | |||
TLV is not used in the Proxy LSP. The format of the Area Proxy TLV | TLV is not used in the Proxy LSP. The format of the Area Proxy TLV | |||
is: | is: | |||
0 1 2 | 0 1 2 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| TLV Type | TLV Length | Sub-TLVs ... | | TLV Type | TLV Length | Sub-TLVs ... | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
TLV Type: YYY | TLV Type: 20 | |||
TLV Length: length of the sub-TLVs | TLV Length: length of the sub-TLVs | |||
3.2. Level 2 SPF Computation | 3.2. Level 2 SPF Computation | |||
When Outside Routers perform a Level 2 SPF computation, they will use | When Outside Routers perform a Level 2 SPF computation, they will use | |||
the Proxy LSP for computing a path transiting the Inside Area. | the Proxy LSP for computing a path transiting the Inside Area. | |||
Because the topology has been abstracted away, the cost for | Because the topology has been abstracted away, the cost for | |||
transiting the Inside Area will be zero. | transiting the Inside Area will be zero. | |||
skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 9 ¶ | |||
Thus, if two paths have different total inter-area metrics, the path | Thus, if two paths have different total inter-area metrics, the path | |||
with the lower inter-area metric would be preferred, regardless of | with the lower inter-area metric would be preferred, regardless of | |||
any intra-area metrics involved. However, if two paths have equal | any intra-area metrics involved. However, if two paths have equal | |||
inter-area metrics, then the intra-area metrics would be used to | inter-area metrics, then the intra-area metrics would be used to | |||
compare the paths. | compare the paths. | |||
Point-to-Point links between two Inside Routers are considered to be | Point-to-Point links between two Inside Routers are considered to be | |||
Inside Area links. LAN links which have a pseudonode LSP in the | Inside Area links. LAN links which have a pseudonode LSP in the | |||
Level 1 LSDB are considered to be Inside Area links. | Level 1 LSDB are considered to be Inside Area links. | |||
3.3. Responsibilities with respect to the Proxy LSP | ||||
The Area Leader will generate a Proxy LSP that must be flooded across | ||||
the Inside Area. Inside Routers MUST ignore the contents of the | ||||
Proxy LSP other than for flooding. | ||||
4. Area Leader Functions | 4. Area Leader Functions | |||
The Area Leader has several responsibilities. First, it MUST inject | The Area Leader has several responsibilities. First, it MUST inject | |||
the Area Proxy System Identifier into the Level 1 LSDB. Second, the | the Area Proxy System Identifier into the Level 1 LSDB. Second, the | |||
Area Leader MUST generate the Proxy LSP for the Inside Area. | Area Leader MUST generate the Proxy LSP for the Inside Area. | |||
4.1. Area Leader Election | 4.1. Area Leader Election | |||
The Area Leader is selected using the election mechanisms and TLVs | The Area Leader is selected using the election mechanisms and TLVs | |||
described in Dynamic Flooding for IS-IS | described in Dynamic Flooding for IS-IS | |||
skipping to change at page 8, line 50 ¶ | skipping to change at page 9, line 13 ¶ | |||
Proxy is active. The format of this sub-TLV is: | Proxy is active. The format of this sub-TLV is: | |||
0 1 2 | 0 1 2 | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | Proxy System ID | | | Type | Length | Proxy System ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Proxy System Identifier continued | | | Proxy System Identifier continued | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Type: AAA | Type: 1 | |||
Length: length of a system ID (6) | Length: length of a system ID (6) | |||
Proxy System Identifier: the Area Proxy System Identifier. | Proxy System Identifier: the Area Proxy System Identifier. | |||
The Area Leader MUST advertise the Area Proxy System Identifier Sub- | The Area Leader MUST advertise the Area Proxy System Identifier Sub- | |||
TLV when it observes that all Inside Routers are advertising the Area | TLV when it observes that all Inside Routers are advertising the Area | |||
Proxy TLV. Their advertisements indicate that they are individually | Proxy TLV. Their advertisements indicate that they are individually | |||
ready to perform Area Proxy functionality. The Area Leader then | ready to perform Area Proxy functionality. The Area Leader then | |||
advertises the Area Proxy System Identifier TLV to indicate that the | advertises the Area Proxy System Identifier TLV to indicate that the | |||
Inside Area MUST enable Area Proxy functionality. | Inside Area MUST enable Area Proxy functionality. | |||
Other candidates for Area Leader MAY also advertise the Area Proxy | Other candidates for Area Leader MAY also advertise the Area Proxy | |||
skipping to change at page 9, line 49 ¶ | skipping to change at page 10, line 17 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | Flags | | | Type | Length | Flags | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SID/Index/Label (variable) | | | SID/Index/Label (variable) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Prefix Length | Prefix (variable) | | | Prefix Length | Prefix (variable) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
where: | where: | |||
Type: BBB | Type: 2 | |||
Length: variable (1 + SID length) | Length: variable (1 + SID length) | |||
Flags: 1 octet. | Flags: 1 octet. | |||
SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 | SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 | |||
Prefix Length: 1 octet | Prefix Length: 1 octet | |||
Prefix: 0-16 octets | Prefix: 0-16 octets | |||
The Flags octet is defined as follows: | The Flags octet is defined as follows: | |||
skipping to change at page 14, line 31 ¶ | skipping to change at page 14, line 46 ¶ | |||
information for the Area SID is distributed to all Inside Edge | information for the Area SID is distributed to all Inside Edge | |||
Routers using the Area SID sub-TLV (Section 4.3.2) by the Area | Routers using the Area SID sub-TLV (Section 4.3.2) by the Area | |||
Leader. | Leader. | |||
The Area Leader SHOULD advertise the Area SID information in the | The Area Leader SHOULD advertise the Area SID information in the | |||
Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1. The | Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1. The | |||
advertisement in the Proxy LSP informs the remainder of the network | advertisement in the Proxy LSP informs the remainder of the network | |||
that packets directed to the SID will be forwarded by one of the | that packets directed to the SID will be forwarded by one of the | |||
Inside Edge Nodes and the Area SID will be consumed. | Inside Edge Nodes and the Area SID will be consumed. | |||
Other uses of the Area SID are outside the scope of this document. | Other uses of the Area SID and area SID prefix are outside the scope | |||
Documents which define other use cases for the Area SID MUST specify | of this document. Documents which define other use cases for the | |||
whether the SID value should be the same or different from that used | Area SID MUST specify whether the SID value should be the same or | |||
in support of Area Proxy. | different from that used in support of Area Proxy. | |||
5. Inside Edge Router Functions | 5. Inside Edge Router Functions | |||
The Inside Edge Router has two additional and important functions. | The Inside Edge Router has two additional and important functions. | |||
First, it MUST generate IIHs that appear to have come from the Area | First, it MUST generate IIHs that appear to have come from the Area | |||
Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial | Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial | |||
Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs | Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs | |||
(CSNPs) that are being advertised to Outside Routers. | (CSNPs) that are being advertised to Outside Routers. | |||
5.1. Generating L2 IIHs to Outside Routers | 5.1. Generating L2 IIHs to Outside Routers | |||
skipping to change at page 15, line 48 ¶ | skipping to change at page 16, line 17 ¶ | |||
6. Acknowledgments | 6. Acknowledgments | |||
The authors would like to thank Bruno Decraene and Gunter Van De | The authors would like to thank Bruno Decraene and Gunter Van De | |||
Velde for their many helpful comments. The authors would also like | Velde for their many helpful comments. The authors would also like | |||
to thank a small group that wishes to remain anonymous for their | to thank a small group that wishes to remain anonymous for their | |||
valuable contributions. | valuable contributions. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This memo requests that IANA allocate and assign one code point from | This memo requests that IANA allocate and assign code point 20 from | |||
the IS-IS TLV Codepoints registry for the Area Proxy TLV (YYY). The | the IS-IS TLV Codepoints registry for the Area Proxy TLV. The | |||
registry fields should be: IIH:n, LSP:y, SNP:n, Purge:n. | registry fields should be: IIH:n, LSP:y, SNP:n, Purge:n. | |||
In association with this, this memo requests that IANA create a | In association with this, this memo requests that IANA create a | |||
registry for code points for the sub-TLVs of the Area Proxy TLV. | registry for code points for the sub-TLVs of the Area Proxy TLV. | |||
Name of the registry: Sub-TLVs for TLV YYY (Area Proxy TLV) | Name of the registry: Sub-TLVs for TLV 20 (Area Proxy TLV) | |||
Required information for registrations: Temporary registrations | Required information for registrations: Temporary registrations | |||
may be made under the Early IANA Allocation of Standards Track | may be made under the Early IANA Allocation of Standards Track | |||
Code Points policy. [RFC7120] Permanent registrations require the | Code Points policy. [RFC7120] Permanent registrations require the | |||
publication of an RFC describing the usage of the code point. | publication of an RFC describing the usage of the code point. | |||
Applicable registration policy: RFC Required and Expert Review. | Applicable registration policy: RFC Required and Expert Review. | |||
We propose the initial experts be Chris Hopps, Tony Li, and Sarah | We propose the initial experts be Chris Hopps, Tony Li, and Sarah | |||
Chen. | Chen. | |||
Size, format, and syntax of registry entries: Value (0-255), Name, | Size, format, and syntax of registry entries: Value (0-255), Name, | |||
and Reference | and Reference | |||
Initial assignments and reservations: IANA is requested to assign | Initial assignments and reservations: IANA is requested to assign | |||
the following code points: | the following code points: | |||
+-------+------------------------------+---------------+ | +-------+------------------------------+---------------+ | |||
| Value | Name | Reference | | | Value | Name | Reference | | |||
+-------+------------------------------+---------------+ | +-------+------------------------------+---------------+ | |||
| AAA | Area Proxy System Identifier | This document | | | 1 | Area Proxy System Identifier | This document | | |||
| BBB | Area SID | This document | | | 2 | Area SID | This document | | |||
+-------+------------------------------+---------------+ | +-------+------------------------------+---------------+ | |||
8. Security Considerations | 8. Security Considerations | |||
This document introduces no new security issues. Security of routing | This document introduces no new security issues. Security of routing | |||
within a domain is already addressed as part of the routing protocols | within a domain is already addressed as part of the routing protocols | |||
themselves. This document proposes no changes to those security | themselves. This document proposes no changes to those security | |||
architectures. | architectures. | |||
9. References | 9. References | |||
End of changes. 24 change blocks. | ||||
31 lines changed or deleted | 45 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/ |