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