Subject: Re: [OSPF] How to handle multiple overlapping SRGB ranges

From: <[email-masked]>
Date: Thu, 25 Jun 2015 13:58:26 +0000

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
> 
> All,
> 
> there's an open question that requires the wg to agree
> 
> The issue here is related to SRGB ranges advertised within the SR-Cap SubTLV.
> 
> The question is: what a receiving router should do when receiving SRGB
> ranges that overlaps ?

Presumably, the question is equally applicable to OSPF, so I'm adding the ospf WG in the discussion.

> Knowing that the spec mandates a single SR-Cap SubTLV, the overlap may
> happen only within the same SR-Cap subTLV and therefore it is clearly a local
> misconfiguration or an implementation bug in the router originating the SR-
> Cap.
> 
> Personally, I would recommend to ignore the whole SRGB (not only the
> overlapping ranges) from the faulty router. Ignoring only the overlapping
> ranges would not work since the whole index space is affected anyway.

Personally, I would recommend ignoring the overlapping SRGB Descriptor and the subsequent ones. But I'd rather keep the SRGB descriptors which are before (the overlaps) as they do not pose a problem. Keeping them preserve the forwarding of the global Segments using them. This seems inline with the IETF  Robustness Principle https://tools.ietf.org/html/rfc1122#section-1.2.2

"      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue."
[...]
"host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility."

In particular "cooperate to limit the amount of disruption"

Thanks
/Bruno
 
> There are different opinions on how the receiving router should behave.
> Ideally, we should converge towards a single solution so feel free to comment.
> 
> Thanks.
> s.
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

_________________________________________________________________________________________________________________________

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 25 Jun 2015 14:32:22 +0000

Bruno -

I am thinking that the behavior you prefer below requires further specification.

Consider an example. We receive the following set of SRGB ranges:

20000-22000
21000-24000
26000-28000

In such a case no one would consider using any of the ranges because the first two overlap - and using the third range  (which does NOT overlap) is likely to be wrong because indices less than 4000 seem like they should be into one of the first two ranges - but we can't really be sure because we don't know which of the three ranges was misconfigured.

Now, here is a second case:

26000-28000
20000-22000
21000-24000

Here, again, we don't know which of the three ranges is misconfigured - but because it is the first range which does not conflict you want us to assume that it must be correct. We actually have no more reason to believe it is correct than we did in the first case - but because it is the first range you propose that we trust it.

Now, the second case "might" be less ambiguous if we had some history - for example, suppose the same router had previously advertised:

26000-28000
20000-22000

Then it advertised the third range (in conflict w second range) shown above. With this history we "might" feel more strongly that the misconfiguration was associated w adding the third range and so it is safe to use the first range. But in the absence of history we really don't know which of the ranges should be considered valid - we are just hoping that the config error (or implementation bug) is confined.

Now, if you want to bring "history" into the specification, things become less predictable because it is possible that a recently booted router won't have the history - and so now all routers won't agree on what should be used and what should not.

This is an example of how complex things can get when we try to define rules about how to deal with a set of information which is in error. This is why, though I appreciate your desire to try to preserve what you hope is usable, taking a simpler approach (ignore) is appealing. 

   Les

> -----Original Message-----
> From: OSPF [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, June 25, 2015 6:58 AM
> To: Stefano Previdi (sprevidi); [email-masked] list
> Cc: [email-masked]
> Subject: Re: [OSPF] How to handle multiple overlapping SRGB ranges
> 
> > happen only within the same SR-Cap subTLV and therefore it is clearly
> > a local misconfiguration or an implementation bug in the router
> > originating the SR- Cap.
> >
> > overlapping ranges) from the faulty router. Ignoring only the
> > overlapping ranges would not work since the whole index space is affected
> anyway.
> 
> Personally, I would recommend ignoring the overlapping SRGB Descriptor
> and the subsequent ones. But I'd rather keep the SRGB descriptors which are
> before (the overlaps) as they do not pose a problem. Keeping them preserve
> the forwarding of the global Segments using them. This seems inline with the
> IETF  Robustness Principle https://tools.ietf.org/html/rfc1122#section-1.2.2
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: <[email-masked]>
Date: Fri, 26 Jun 2015 07:24:11 +0000

Hi Les

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]] > Sent: Thursday, June 25, 2015 4:32 PM
> 
> Bruno -
> 

Sure. I'm all for the specification.
Let me just recap my proposal:
- SRGB descriptor _are_   already ordered
- I propose to consider the SRGB descriptors in this order, accept all valid ones until we find some in errors. If which cases stop considering further descriptors as they are at risk.

> In such a case no one would consider using any of the ranges because the first
> two overlap - and using the third range  (which does NOT overlap) is likely to
> be wrong because indices less than 4000 seem like they should be into one of
> the first two ranges - but we can't really be sure because we don't know
> which of the three ranges was misconfigured.

So we agree on this one.
 
> Here, again, we don't know which of the three ranges is misconfigured - but
> because it is the first range which does not conflict you want us to assume that
> it must be correct. We actually have no more reason to believe it is correct
> than we did in the first case - but because it is the first range you propose that
> we trust it.

I propose to accept the SRGB descriptors until there is a problematic one.
There is no issue with the first SRGB ranges. There is no reason to believe that the originator is not capable of doing the sum (SRGB+index) and program the result in its MPLS ILM (Incoming Label Map). 

> Now, the second case "might" be less ambiguous if we had some history - for
> example, suppose the same router had previously advertised:
> 
> 26000-28000
> 20000-22000
> 
> Then it advertised the third range (in conflict w second range) shown above.
> With this history we "might" feel more strongly that the misconfiguration was
> associated w adding the third range and so it is safe to use the first range. But
> in the absence of history we really don't know which of the ranges should be
> considered valid - we are just hoping that the config error (or implementation
> bug) is confined.
> 
> Now, if you want to bring "history" into the specification, things become less
> predictable

I have never talked about bringing history in the picture.
Let's discuss my proposition, rather than building something different to better disregard it.

> because it is possible that a recently booted router won't have
> the history - and so now all routers won't agree on what should be used and
> what should not.
> 
> This is an example of how complex things can get when we try to define rules
> about how to deal with a set of information which is in error. This is why,
> though I appreciate your desire to try to preserve what you hope is usable,
> taking a simpler approach (ignore) is appealing.

_You_ changed the proposition to make it complex by introducing history.

Again, let's discuss the proposition on the table.

In term of complexity:
In both propositions  you need to
- parse SRGB descriptor, presumably in order.
- detect inconsistency between SRGB descriptors.
- log the error

a) With my proposition, you stop the SRGB parsing here and do nothing else.
b) With your proposition, you need to roll back and remove previous SRGB descriptor.

It's not clear to me why "a" (i.e. do nothing) is more complex than "b" (roll back).

Now, it would be good to also discuss the impact on the customer traffic of both approaches:
- if the node is considered non SRGB capable, all traffic for all FEC crossing that node is dropped. In a MPLS VPN network where all traffic is MPLS, this is a big impact
- if we only disregard the problematic SRGB descriptors, we save part of the traffic. How much of the traffic is purely hypothesis dependent. However as the spec recommend (SHOULD) to add new SRGB descriptor at the end, typically all existing traffic would be unaffected.

So in summary, using the valid SRGB descriptors:
- brings no issue
- is equally simple
- provides a significant protection of existing traffic.

Indeed, some existing implementation may need to be touched, but the change does not bring interoperability issue (compared to the previous one on this subject, at least for IS-IS)

/Bruno
 
> > > The issue here is related to SRGB ranges advertised within the
> > > SR-Cap
> > SubTLV.
> > >
> > > The question is: what a receiving router should do when receiving
> > > SRGB ranges that overlaps ?
> >
> > > Knowing that the spec mandates a single SR-Cap SubTLV, the overlap
> > > may happen only within the same SR-Cap subTLV and therefore it is
> > > clearly a local misconfiguration or an implementation bug in the
> > > router originating the SR- Cap.
> > >
> > and the subsequent ones. But I'd rather keep the SRGB descriptors
> > which are before (the overlaps) as they do not pose a problem. Keeping
> > them preserve the forwarding of the global Segments using them. This
> > seems inline with the IETF  Robustness Principle
> > https://tools.ietf.org/html/rfc1122#section-1.2.2
> >
> > > Ideally, we should converge towards a single solution so feel free
> > > to
> > comment.
> > >
> > > Thanks.
> > > s.
> > >
> > 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.