Subject: Re: [spring] A question regarding Section 3.2 of RFC 8402

From: Peter Psenak <[email-masked]>
Date: Thu, 9 Jan 2020 14:13:38 +0100

Hi Alexander,

On 10/12/2019 12:13, Alexander Vainshtein wrote:
> Hi all,
> 
> My colleagues and I have a question pertaining to Section 3.2 of RFC 
> 8402 
> <https://eci365.sharepoint.com/sites/technicaldocsite/genericdev/System/System%20Documents/Forms/AllItems.aspx?FolderCTID=0x012000858C3D81A4889F449868AC62A2AABDCD&id=%2Fsites%2Ftechnicaldocsite%2Fgenericdev%2FSystem%2FSystem%20Documents%2FIP%2DMPLS%2FNE%20Management%2FCLI>. 
> This section says:
> 
>     An IGP Node-SID MUST NOT be associated with a prefix that is owned by
> 
>     more than one router within the same routing domain.
> 
> The requirement itself is well understood. However, neither RFC 8402 nor 
> any other SPRING document I have seen defines the expected behavior of 
> SR-capable nodes if, due to misconfiguration, a certain prefix that is 
> owned by multiple nodes in the SR domain is associated with the Node-SID 
> in at least one of them.
> 
> There are several sub-scenarios of the misconfiguration problem above, e.g.:

there are way too many ways how one can misconfigure things and I don't 
believe we have to always standardize the way these errors are handled.

> 
> ·The prefix is owned by multiple nodes. One of these nodes advertises it 
> as associated with the Node-SID, while the other owners do not associate 
> it with any SID at all
> 
> ·The prefix is owned by multiple nodes. One of these nodes advertises it 
> as associated with the Node-SID, while one (or more) of the other nodes 
> advertise it as associated with an IGP-Prefix SID but not as a Node-SID

Above two are similar in a nature. Prefix is anycast, but at least one 
node advertise a Node-SID with such anycast prefix.

There are ways to detect the anycast prefix property - one is defined in 
the section 6 of draft-ietf-lsr-isis-srv6-extensions - e.g. A-flag. That 
section says:

"If at least one of them sets the A-Flag in its advertisement, the
  prefix/SRv6 Locator SHOULD be considered as anycast."

If the prefix is considered anycast, one should not use the SID 
advertised with the prefix as Node-SID, even when the N-flag is set for it.

Other way to detect the prefix is anycast one is simply looking at the 
number of sources that advertise it.

> 
> ·The prefix is owned by multiple nodes, and  two (or more) of these 
> nodes advertise it as associated with the Node-SID but with different 
> indices in the SRGB

this is SID conflict, where you have multiple sources of the same prefix 
advertising a different SID value.

There used to be a draft that went into details of all possible SID 
conflicts (draft-ietf-spring-conflict-resolution), but it became way too 
complex and people lost interest.

> 
> ·The prefix is owned by multiple nodes, and  two (or more) of these 
> nodes advertise it as associated with the Node-SID with the same index 
> in the SRGB.

problem is the same as the first two. Prefix is anycast, but at least 
one node advertise a Node-SID wit the anycast prefix.

thanks,
Peter

> 
> Our experiments (admittedly incomplete) with SR-capable equipment from 
> different vendors have shown that:
> 
> ·None of the tested devices have reported this situation as an error 
> when they encounter some of the problematic scenarios
> 
> ·Different devices have demonstrated different forwarding behavior when 
> they encounter some of the problematic scenarios. In some of these 
> scenarios the offending prefix would be associated with some SID and the 
> resulting forwarding behavior installed.
> 
> We think that it would be nice if the WG could define a minimal set of 
> requirements for handling this kind of misconfiguration. These 
> requirements should include at least the following:
> 
> ·A device that encounters this kind of misconfiguration SHOULD report 
> the problem to the network management layer
> 
> ·The prefix for which this kind of misconfiguration has been detected 
> SHOULD NOT be associated with any IGP Prefix-SID at all.
> 
> There may be other possibilities, but we feel that RFC 8402 is 
> underspecified in this regard,
> 
> We would highly appreciate your feedback.
> 
> Regards, and lots of thanks in advance,
> 
> Sasha (on behalf of the team).
> 
> Office: +972-39266302
> 
> Cell:      +972-549266302
> 
> Email:   [email-masked]
> 
> 
> ___________________________________________________________________________
> 
> 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.
> ___________________________________________________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 9 Jan 2020 14:00:09 +0000

Peter,

Lots of thanks for your response.

I fully agree with you when you say that "there are way too many ways how one can misconfigure things".

However, I think that in many cases IETF tries to standardize handling of these misconfigurations, and, specifically for RFC 8660<https://tools.ietf.org/html/rfc8660> deals with some of these misconfigurations in Section 2.5 and in Appendix A (BTW, the SPRING conflict resolution draft that you mention has been, with some modifications, subsumed into these sections of  RFC 8660).

However, the conflicts that I have described are not covered by RFC 8660 since it only speaks about incoming label conflicts when the same incoming label is mapped to multiple segments. Our case is different, since we have just one Prefix Segment (same prefix, same topology and same algorithm).

Regarding your references to IPv6: I think that there is a subtle difference between SR-MPLS and SRv6 when it comes to Node SIDs:

-          In SRv6,  you can explicitly mark the prefix as either Anycast or Node SID with the preference given to Anycast (if both N-flag and A-flag are set, N-flag is ignored, if one of the routers that own a prefix advertises with A-flag set, the prefix becomes an Anycast one)

-          In SR-MPLS you have to explicitly indicate that a given prefix (/32 for IPv4 and /128 for IPv6) is a Node Segment. Without this indication the Prefix SID is (implicitly) an Anycast one (see RFC 8667<https://www.rfc-editor.org/rfc/rfc8667.html>).

Based on this I still think that the problem my colleagues and I have raised is relevant and should be addressed.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Peter Psenak <[email-masked]>
Sent: Thursday, January 9, 2020 3:14 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: Madhav Purohit <[email-masked]>; Dmitry Valdman <[email-masked]>; Michael Gorokhovsky <[email-masked]>; Abhijit Gokaraju <[email-masked]>; Sheetal Jangeed <[email-masked]>
Subject: Re: [spring] A question regarding Section 3.2 of RFC 8402

Hi Alexander,

>     An IGP Node-SID MUST NOT be associated with a prefix that is owned

> by

> The requirement itself is well understood. However, neither RFC 8402

> nor any other SPRING document I have seen defines the expected

> behavior of SR-capable nodes if, due to misconfiguration, a certain

> prefix that is owned by multiple nodes in the SR domain is associated

> with the Node-SID in at least one of them.

> There are several sub-scenarios of the misconfiguration problem above, e.g.:

there are way too many ways how one can misconfigure things and I don't believe we have to always standardize the way these errors are handled.

> ·The prefix is owned by multiple nodes. One of these nodes advertises

> it as associated with the Node-SID, while the other owners do not

> associate it with any SID at all

> ·The prefix is owned by multiple nodes. One of these nodes advertises

> it as associated with the Node-SID, while one (or more) of the other

> nodes advertise it as associated with an IGP-Prefix SID but not as a

> Node-SID

Above two are similar in a nature. Prefix is anycast, but at least one node advertise a Node-SID with such anycast prefix.

There are ways to detect the anycast prefix property - one is defined in the section 6 of draft-ietf-lsr-isis-srv6-extensions - e.g. A-flag. That section says:

If the prefix is considered anycast, one should not use the SID advertised with the prefix as Node-SID, even when the N-flag is set for it.

Other way to detect the prefix is anycast one is simply looking at the number of sources that advertise it.

thanks,

Peter

> Email:   [email-masked]<mailto:[email-masked]>

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.
___________________________________________________________________________

---

From: Peter Psenak <[email-masked]>
Date: Thu, 9 Jan 2020 15:09:37 +0100

Hi Sasha,

please see inline:

On 09/01/2020 15:00, Alexander Vainshtein wrote:
> However, I think that in many cases IETF tries to standardize handling 
> of these misconfigurations, and, specifically for RFC 8660 
> <https://tools.ietf.org/html/rfc8660> deals with some of these 
> misconfigurations in Section 2.5 and in Appendix A (BTW, the SPRING 
> conflict resolution draft that you mention has been, with some 
> modifications, subsumed into these sections of  RFC 8660).
> 
> However, the conflicts that I have described are not covered by RFC 8660 
> since it only speaks about incoming label conflicts when the same 
> incoming label is mapped to multiple segments. Our case is different, 
> since we have just one Prefix Segment (same prefix, same topology and 
> same algorithm).
> 
> Regarding your references to IPv6: I think that there is a subtle 
> difference between SR-MPLS and SRv6 when it comes to Node SIDs:
> 
> -In SRv6,  you can explicitly mark the prefix as either Anycast or Node 
> SID with the preference given to Anycast (if both N-flag and A-flag are 
> set, N-flag is ignored, if one of the routers that own a prefix 
> advertises with A-flag set, the prefix becomes an Anycast one)
> 
> -In SR-MPLS you have to explicitly indicate that a given prefix (/32 for 
> IPv4 and /128 for IPv6) is a Node Segment. Without this indication the 
> Prefix SID is (implicitly) an Anycast one (see RFC 8667 
> <https://www.rfc-editor.org/rfc/rfc8667.html>).

A-flag and N-flag are prefix attributes flags and they are applicable 
equally to both IPv4 and IPv6 prefixes as well as SRv6 Locators.

thanks,
Peter

> 
> Based on this I still think that the problem my colleagues and I have 
> raised is relevant and should be addressed.
> 
> Regards,
> 
> Sasha
> 
> Office: +972-39266302
> 
> Cell:      +972-549266302
> 
> Cc: Madhav Purohit <[email-masked]>; Dmitry Valdman 
> <[email-masked]>; Michael Gorokhovsky 
> <[email-masked]>; Abhijit Gokaraju 
> <[email-masked]>; Sheetal Jangeed 
> <[email-masked]>
> <mailto:[email-masked]>
> 
>  >
> 
>  >
> 
>  >