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

<> Thu, 25 June 2015 13:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 16B561A8904; Thu, 25 Jun 2015 06:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wlPkfS6PA7bJ; Thu, 25 Jun 2015 06:58:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F0FB1A88F6; Thu, 25 Jun 2015 06:58:29 -0700 (PDT)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 884A722CAE5; Thu, 25 Jun 2015 15:58:27 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 66F5D27C059; Thu, 25 Jun 2015 15:58:27 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0235.001; Thu, 25 Jun 2015 15:58:27 +0200
From: <>
To: "Stefano Previdi (sprevidi)" <>, " list" <>
Thread-Topic: How to handle multiple overlapping SRGB ranges
Thread-Index: AQHQr0wkXCw5I88510e7JcWFLoNcd529Oo0w
Date: Thu, 25 Jun 2015 13:58:26 +0000
Message-ID: <3082_1435240707_558C0903_3082_1021_2_53C29892C857584299CBF5D05346208A0F5C7A1C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.6.2.75418
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 13:58:35 -0000

> 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
"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"

> 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.