Re: [Isis-wg] How to handle multiple overlapping SRGB ranges

"Les Ginsberg (ginsberg)" <> Thu, 25 June 2015 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 35E121A8988; Thu, 25 Jun 2015 07:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PdPR27qIPRbR; Thu, 25 Jun 2015 07:32:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6F871A8987; Thu, 25 Jun 2015 07:32:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6429; q=dns/txt; s=iport; t=1435242756; x=1436452356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=u78LPBt0+jNAgPZUTP1a8q0m45Lzs5fOQaSxMdkJiZQ=; b=maanaepaq+hQBE8f/bSf9QsAdiuI3ZNABWLayBoDxYRwaLNxZEzfaxna N4Vd9PCc/og3ker9ALlqeXQzk4wYdE9UuICdGTVMQlNG/HxUlmcE2amQz OMpbkMHKu3rqmDF1jzkmjVg2JykHrCzLCQrpwGe4kR9dvM3Hc81PRaVi0 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,677,1427760000"; d="scan'208";a="6547543"
Received: from ([]) by with ESMTP; 25 Jun 2015 14:32:23 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5PEWNPt019880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 14:32:23 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 09:32:23 -0500
From: "Les Ginsberg (ginsberg)" <>
To: "" <>, "Stefano Previdi (sprevidi)" <>, " list" <>
Thread-Topic: How to handle multiple overlapping SRGB ranges
Thread-Index: AQHQr0wkXCw5I88510e7JcWFLoNcd529Oo0wgAALN4A=
Date: Thu, 25 Jun 2015 14:32:22 +0000
Message-ID: <>
References: <> <3082_1435240707_558C0903_3082_1021_2_53C29892C857584299CBF5D05346208A0F5C7A1C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <3082_1435240707_558C0903_3082_1021_2_53C29892C857584299CBF5D05346208A0F5C7A1C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Isis-wg] How to handle multiple overlapping SRGB ranges
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jun 2015 14:32:39 -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:


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:


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:


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. 


> -----Original Message-----
> From: OSPF [] On Behalf Of
> Sent: Thursday, June 25, 2015 6:58 AM
> To: Stefano Previdi (sprevidi); list
> Cc:
> Subject: Re: [OSPF] How to handle multiple overlapping SRGB ranges
> > From: Isis-wg [] 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
> "      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
> >
> >
> __________________________________________________________
> __________________________________________________________
> _____
> 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.
> _______________________________________________
> OSPF mailing list