Hi Les, authors, WG
As an individual contributor, please find below some more detailed comments and
considerations on the draft.
Following the "please send text" request expressed during the meeting, please
find enclosed some proposed text. (xml, txt, diff versus public version).
I wished I had sent this before, but writing the text took longer than
expected. BTW I still not happy with my text, but hopefully current text (or
at least the table of content) should be enough to give an idea on the
direction I have in mind.
Thanks,
Regards,
Bruno
__
As previous expressed on the mailing list and during the meeting, I'm
especially concerned with Mapping Server advertisement where a single typo/bug
can conflict with many/all SIDs in the network. In this case, I don't think
that dropping all traffic to those SIDs is a desirable option.
One option is to prefer individual advertisement (prefix SID) over general ones
(Mapping Server). i.e. more specific wins. Note that this is the approach
currently taken by the IS-IS draft:
" For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV
and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the
Prefix-SID advertised within the Prefix TLV MUST be preferred while
the MS entry MUST be ignored."
We can probably assume that this is already implemented (by compliant
implementations), so I'm not sure to see the value of changing existing
implementations if this is to get a more disruptive result for the network.
__
Regarding SID conflict, the current draft proposes to drop all conflicting
information.
Looking at the big picture, this means: the more (Mapping Server) redundancy,
the more risk of conflict, the less availability.
This is probably not the property that we are looking for.
__
I support the comment to consider the error handling work "recently" done in
the IDR WG. IMHO, WG and authors did a good work on such a difficult subject (just like
for SID conflicts, at the beginning opinions were diverse, and everyone had good reasons).
I'm not sure how much reading the end result (RFC 7606) helps in understanding
all the trade-off considered during the work. Reading the operational
requirements, given that the IGP infrastructure is probably even more important
than BGP for network operators/clients/traffic, it may be worthwhile to read
BGP error handling operation requirements (
https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07
) Discussion with the people involved may help. FYI, as for me, the point I
learnt are:
- when we detect an error on the receiving side, there is a bug. In general, it's
difficult to know whether the bug is on the sending side or the receiving side. Clearly,
for the receiving side, the first reaction is to blame the sending side. For each error,
it's useful to consider both options (i.e. error may be on my/receiving side). And even
if the error is on the sending side, the receiver may run the same implementation (so
"sender is too buggy to live" may apply to your own implementation i.e. the
receiving side).
- when we detect an error, it's useful to consider all possible causes and
consequences before deciding to make things worse (e.g. killing a
session/transit node/prefix). In particular, there may not be a single error
but many (SIDs, source routers (especially if the error is on the receiving
side)). So it's useful to consider that the decision may be multiplied 10 or
100 times.
Clearly there are difference between IGP & BGP: usually more redundancy in BGP
(more signaling path (redundant RR) and more AS exit points), more prefixes hence
the cost of dropping one prefix is relatively less important, two-way point to
point signaling channel, messages are flooded unchanged so people are less likely
to shoot the messenger and errors are less likely to be multiplied during
propagation....
__
"An
alternative is to ensure at the nodes which originate these
advertisements that no such overlap is allowed to be configured.
Such overlaps can then be considered as a conflict if they are
received. This allows a simpler and more efficient implementation of
the database. This is the approach assumed in this document."
I encourage implementation to check the configurations before accepting it. And
to check its routing advertisement before sending it. I would assume that state
of the art implementation will do it. Yet, I don't think it should be
considered as an excuse to avoid error handling at the protocol level.
BTW, I'm not sure how much you expect implementation checks to be done before
committing/sending. e.g. If an operator configure a range on the SRMS, and this
ranges conflict with existing SID advertised by other nodes, would you expect
the implementation to detect such conflict and reject the configuration?
More generally, if we assume some extensive checks by implementations before
committing/sending, and that given such assumption we define a light error
handling, I'd like such assumptions be documented in the document and probably
be made normative (since the receiving side, is expected a specific behavior
from the sending side, this is normative).
Also "implementation of the database" is implementation dependent and is
probably just one aspect of the implementation simplicity/efficiency.
And speaking for myself, simplicity/efficiency/availability of 100s networks running
segment routing significantly out weight the "simplicity and efficiency" of one
to ten implementations.
__
"The occurrence of conflicts is
easily diagnosed from the behavior of the network as the forwarding
of traffic which would, in the absence of conflicts, utilize
segments no longer does so."
I don't think that we need to kill customer's traffic to raise awareness of the
network operator. And I don't support the idea that the more traffic you kill,
the easier and faster the error is resolved.
If you need to raise an error, please do so! e.g. in logs, syslogs, SNMP traps,
netconf event notification... Dropping the traffic is not providing more
information, it is increasing the pressure and hence the probability of quick
erroneous actions. Not to mention that as all services will run over packet
networks, and as there is a pressure to reduce costs we may have a single
converged network for all services. In this case, there is a chance that if the
network is down, some people/tools/equipment may not be reached anymore/easily.
e.g. calling people on their cell phone does not work when the packet network
is down.
__
" The downside of ignoring conflicting entries is that forwarding of
all packets with destinations covered by the conflicting entries will
always be negatively impacted."
Let's call a spade a spade. (btw, I prefer the French version :s/spade/cat
which nowadays should be more popular on the Internet ;-) )
The traffic is not "negatively impacted", the traffic is "dropped". And for all
services/customers/BGP routes using theses SIDs.
__
3.2.2. Preference Algorithm
[...]
"This approach requires that conflicting entries first be identified"
All approach requires conflicting entries to be identified. This is not a drawback of the
"preference algorithm"
"Based on which entry is preferred this in turn may impact what other entries are
considered in conflict"
This is not additional rule/work. This is applying the same rule/algo to
subsequent entries.
Also, from the network perspective, in the end, this will not drop more entries than the
"ignore rule", quite the contrary.
"Based on
which entry is preferred this in turn may impact what other entries
are considered in conflict i.e. if A conflicts with B and B
conflicts with C - it is possible that A does NOT conflict with C.
Hence if as a result of the evaluation of the conflict between A and
B, entry B is not used the conflict between B and C will not be
considered."
I'm not sure to get what is implied. As A and B conflicts and B and C conflicts, with "ignore
conflicting entries", I would assume that all A, B, C be ignored, no? Or do you plan to ignore
conflicting entries until there is no conflict? In which case we would only remove one of the two
conflicting entries and end up with a "preference" resolution 'and never drop both
conflicting entries since once we drop the first, there is no more conflict)
___
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
