Vahid,
You are welcome.
Thumb typed by Sasha Vainshtein
________________________________
From: vahid tavajjohi <[email protected]>
Sent: Sunday, April 14, 2019 6:36:01 PM
To: Alexander Vainshtein
Cc: [email protected]
Subject: Re: [spring] Anycast-SID
Sasha,
Thanks for your time to respond my emails.
Regards,
Vahid
[email protected]<mailto:[email protected]>
On Apr 14, 2019, at 5:19 PM, Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
wrote:
Vahid,
The SPRING WG mailing list is not a proper forum for discussing proprietary
tutorials.
They should rather be discussed with whoever has published them,
Regarding your reference to Anycast-SID appearing as the first SID in the list
– well, it is a matter of interpretation. From my POV all SID lists implicitly
begin with some identification of the head-end node, so what you see as the
first SID in the list looks as the 2nd SID in the implicit list.
My 2c,
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 2:16 PM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [spring] Anycast-SID
Sasha,
Sorry, but I don’t get my answer.
Also, in SRTE document on “
http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/
", you can see that it uses Anycast-SID as first SID of SID list (Page 48).
<image001.png>
Also, in Cisco affiliated website: “
https://xrdocs.io/design/blogs/2018-05-09-metro-design-implementation-guide/ “
you can see that they use Anycast prefix (on two nodes) with one SID, without
clearing N-flag clear. (violating RFC 8402 section 3.2)
<image002.png>
And these things confused me for meaning of Anycast-SID and effect of violating
RFC8402 rules in network.
I think SPRING WG, should add more and specific explanation for Anycast models
and usages.
Regards,
Vahid
[email protected]<mailto:[email protected]>
On Apr 14, 2019, at 3:22 PM, Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
wrote:
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]<mailto:[email protected]>
From: vahid tavajjohi
<[email protected]<mailto:[email protected]>>
Sent: Sunday, April 14, 2019 1:02 PM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[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.
___________________________________________________________________________
___________________________________________________________________________
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
