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

[Peter Psenak <[e-mail]>]

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: [phone]
> 
> Cell:      [phone]
> 
> Email:   [e-mail]
> 
> 
> ___________________________________________________________________________
> 
> 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.
> ___________________________________________________________________________