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 Email: alexander.vainsht...@ecitele.com -----Original Message----- From: Peter Psenak <ppse...@cisco.com> Sent: Thursday, January 9, 2020 3:14 PM To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; spring@ietf.org Cc: Madhav Purohit <madhav.puro...@ecitele.com>; Dmitry Valdman <dmitry.vald...@ecitele.com>; Michael Gorokhovsky <michael.gorokhov...@ecitele.com>; Abhijit Gokaraju <abhijit.gokar...@ecitele.com>; Sheetal Jangeed <sheetal.jang...@ecitele.com> Subject: Re: [spring] A question regarding Section 3.2 of RFC 8402 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: > alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com> > > > ___________________________________________________________________________ > > 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
