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]> 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]> > 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 > <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
