rfc9572v2.txt | rfc9572.txt | |||
---|---|---|---|---|
skipping to change at line 497 ¶ | skipping to change at line 497 ¶ | |||
| If the received Inter-AS A-D route carries the PMSI Tunnel | | If the received Inter-AS A-D route carries the PMSI Tunnel | |||
| attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then | | attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then | |||
| the ASBR that originated the route MUST establish an RSVP-TE P2MP | | the ASBR that originated the route MUST establish an RSVP-TE P2MP | |||
| LSP with the local PE/ASBR as a leaf. This LSP MAY have been | | LSP with the local PE/ASBR as a leaf. This LSP MAY have been | |||
| established before the local PE/ASBR receives the route, or it MAY | | established before the local PE/ASBR receives the route, or it MAY | |||
| be established after the local PE receives the route. | | be established after the local PE receives the route. | |||
is changed to the following when applied to EVPNs: | is changed to the following when applied to EVPNs: | |||
| If the received Inter-AS A-D route has the L flag set in its PTA, | | If the received Inter-AS A-D route has the L flag set in its PTA, | |||
| then a receiving PE MUST originate a corresponding Leaf A-D route, | | then a receiving PE MUST originate a corresponding Leaf A-D route. | |||
| while a receiving ASBR MUST originate a corresponding Leaf A-D | | A receiving ASBR MUST originate a corresponding Leaf A-D route if | |||
| route if and only if it received and imported one or more | | and only if one of the following conditions is met: (1) it | |||
| corresponding Leaf A-D routes from its downstream IBGP or EBGP | | received and imported one or more corresponding Leaf A-D routes | |||
| peers, or it has non-null downstream forwarding state for the PIM/ | | from its downstream IBGP or EBGP peers or (2) it has non-null | |||
| mLDP tunnel that instantiates its downstream intra-AS segment. | | downstream forwarding state for the PIM/mLDP tunnel that | |||
| The targeted ASBR for the Leaf A-D route, which (re-)advertised | | instantiates its downstream intra-AS segment. The targeted ASBR | |||
| the Inter-AS A-D route, MUST establish a tunnel to the leaves | | for the Leaf A-D route, which (re-)advertised the Inter-AS A-D | |||
| discovered by the Leaf A-D routes. | | route, MUST establish a tunnel to the leaves discovered by the | |||
| Leaf A-D routes. | ||||
5.2. I-PMSI Leaf Tracking | 5.2. I-PMSI Leaf Tracking | |||
An ingress PE does not set the L flag in its IMET A-D route's PTA, | An ingress PE does not set the L flag in its IMET A-D route's PTA, | |||
even with ingress replication or RSVP-TE P2MP tunnels. It does not | even with Ingress Replication tunnels or RSVP-TE P2MP tunnels. It | |||
rely on the Leaf A-D routes to discover leaves in its AS, and | does not rely on the Leaf A-D routes to discover leaves in its AS, | |||
Section 11.2 of [RFC7432] explicitly states that the L flag must be | and Section 11.2 of [RFC7432] explicitly states that the L flag must | |||
set to 0. | be set to 0. | |||
An implementation of [RFC7432] might have used the Originating | An implementation of [RFC7432] might have used the Originating | |||
Router's IP Address field of the IMET A-D routes to determine the | Router's IP Address field of the IMET A-D routes to determine the | |||
leaves or might have used the Next Hop field instead. Within the | leaves or might have used the Next Hop field instead. Within the | |||
same AS, both will lead to the same result. | same AS, both will lead to the same result. | |||
With segmentation, an ingress PE MUST determine the leaves in its AS | With segmentation, an ingress PE MUST determine the leaves in its AS | |||
from the BGP next hops in all its received IMET A-D routes, so it | from the BGP next hops in all its received IMET A-D routes, so it | |||
does not have to set the L flag to request Leaf A-D routes. PEs | does not have to set the L flag to request Leaf A-D routes. PEs | |||
within the same AS will all have different next hops in their IMET | within the same AS will all have different next hops in their IMET | |||
skipping to change at line 788 ¶ | skipping to change at line 789 ¶ | |||
determines the leaves based on the BGP next hops in its received | determines the leaves based on the BGP next hops in its received | |||
I-PMSI A-D routes, as specified in Section 5.2. | I-PMSI A-D routes, as specified in Section 5.2. | |||
The same backward-compatibility issue exists, and the same solution | The same backward-compatibility issue exists, and the same solution | |||
as that for the inter-AS case applies, as specified in Section 5.3. | as that for the inter-AS case applies, as specified in Section 5.3. | |||
7. Multihoming Support | 7. Multihoming Support | |||
To support multihoming with segmentation, Ethernet Segment Identifier | To support multihoming with segmentation, Ethernet Segment Identifier | |||
(ESI) labels SHOULD be allocated from a "Domain-wide Common Block" | (ESI) labels SHOULD be allocated from a "Domain-wide Common Block" | |||
(DCB) [RFC9573] for all tunnel types, including ingress replication | (DCB) [RFC9573] for all tunnel types, including Ingress Replication | |||
tunnels [RFC7988]. Via means outside the scope of this document, PEs | tunnels [RFC7988]. Via means outside the scope of this document, PEs | |||
know that ESI labels are from a DCB, and existing multihoming | know that ESI labels are from a DCB, and existing multihoming | |||
procedures will then work "as is" (whether a multihomed Ethernet | procedures will then work "as is" (whether a multihomed Ethernet | |||
Segment spans segmentation regions or not). | Segment spans segmentation regions or not). | |||
Not using DCB-allocated ESI labels is outside the scope of this | Not using DCB-allocated ESI labels is outside the scope of this | |||
document. | document. | |||
8. IANA Considerations | 8. IANA Considerations | |||
End of changes. 3 change blocks. | ||||
14 lines changed or deleted | 15 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |