Vahid, Anycast-SID can be used in the middle of the list of SIDs defining a SR-TE LSP.
Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: vahid tavajjohi <[email protected]> Sent: Sunday, April 14, 2019 1:02 PM To: Alexander Vainshtein <[email protected]> Cc: [email protected] Subject: Re: [spring] Anycast-SID Sasha, RFC 8402 section 3.3.1 illustrated and mentioned that Group A members are using anycast address 192.0.2.10/32 and the Anycast-SID 100. So, is N-flag cleared? and how they used /32? Also, “ draft-ietf-isis-segment-routing-extensions-23” section 2.1.1.2 states that “ The router MUST ignore the N-Flag on a received Prefix-SID if the prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6)”. So, if I use prefix greater than /32, routers ignores n-flag and there is no need to clear n-flag by my self. I glad to clarify me for these. On Apr 14, 2019, at 1:49 PM, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: Vahid, RFC 8402 states that “IGP-Anycast segment MUST NOT reference a particular node” while the /32 IPv4 address that iBGP advertises as the NH of VPN-IP routes of course references a particular node, namely one the has allocated the labels in these routes. I.e., if you clear N-Flag, you MUST NOT use the /32 IPv4 address in the prefix as the BGP NH in any labeled routes advertised by this node. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> From: vahid tavajjohi <[email protected]<mailto:[email protected]>> Sent: Sunday, April 14, 2019 11:49 AM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [spring] Anycast-SID Sasha, Ok it is clear. Based on your scenario, If I set Anycast-SID and clear N-Flag , problem will solve? Regards, Vahid On Apr 14, 2019, at 12:25 PM, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]> From: vahid tavajjohi <[email protected]<mailto:[email protected]>> Sent: Sunday, April 14, 2019 10:45 AM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[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. ___________________________________________________________________________ ___________________________________________________________________________ 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
