Vahid, This is not about PCE, it is (eventually) about traffic. May I suggest that you perform the following test:
1. Define the same IPv4 /32 prefix in two nodes A and B as a Node-SID. 2. Set up a BGP/MPLS IP VPN service that is represented in nodes A and C, but not in Node B and that uses shortest path SR LSPs as tunnels. Take care of iBGP in A using the IP address in question as the NH of VPN-IP routes it advertises while not defining BGP in B. 3. Run test traffic over this service with ingress in C and (expected) egress in A. You will see that, this traffic will pass if Dist (C A) < Dist (C, B), and will be blackholed if Dist (C, A) > Dist (C, B). And this is all you need to know. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: vahid tavajjohi <[email protected]> Sent: Sunday, April 14, 2019 10:45 AM To: Alexander Vainshtein <[email protected]> Cc: [email protected] Subject: Re: [spring] Anycast-SID Sasha, It is obvious that it violates rules, my point is what happens in the network. I can’t find any clue in my LAB environment and any other documents. I don’t clear N-FLAG in anycast but PCE uses Anycast-SID in SRTE. I clear N-FLAG in anycast, PCE does not uses Anycast-SID but I tried SRTE with explicit-path, it worked correctly. So, my point is there are no explanation that describes effect of violating rules. Also, definition of Anycast-SID is not clear. For example, is Anycast for plane separation is different than Anycast for HA(ABR) or not? I hope my explanation is clear. Regards, Vahid On Apr 14, 2019, at 11:55 AM, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: Vahid, Section 2.1.1.2 of the IS-IS Extensions for Segment Routing<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-23> draft defines N-Flag in the Prefix-SID Sub-TLV as following (the relevant text is highlighted): N-Flag: Node-SID flag. If set, then the Prefix-SID refers to the router identified by the prefix. Typically, the N-Flag is set on Prefix-SIDs attached to a router loopback address. The N-Flag is set when the Prefix-SID is a Node-SID as described in [RFC8402<https://tools.ietf.org/html/rfc8402>]. An RF C 8402 states in Section 3.2: An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain. Therefore, the answer to your first question “What happens if I don’t implement these rules in network?” is simple: Your implementation violates a mandatory requirement of the Segment Routing architecture. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> -----Original Message----- From: spring <[email protected]<mailto:[email protected]>> On Behalf Of vahid tavajjohi Sent: Saturday, April 13, 2019 7:39 AM To: [email protected]<mailto:[email protected]> Subject: [spring] Anycast-SID Hi SPRING WG, I have a question about Anycast-SID. 1- In RFC 8402 section 3.2, it mentioned that “Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain”. Also, in section 3.3, it mentioned that “ An IGP-Anycast segment MUST NOT reference a particular node”. 2- Also, we have N-Flag “isis-segment-routing-extensions-23” that indicates whether Prefix-SID related to a node or not. My questions are: 1- What happens if I don’t implement these rules in network? 2- What happens if I set anycast-sid on multiple nodes, but I don’t set "n-flag clear” under loopback configuration? 3- Why "IGP-Anycast segment MUST NOT reference a particular node” ? Best Regards, Vahid _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
