IETF Logo Mail Archive

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

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Thu, 25 June 2015 13:38 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43441A886C for <isis-wg@ietfa.amsl.com>; Thu, 25 Jun 2015 06:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXgIvJ_XRIo1 for <isis-wg@ietfa.amsl.com>; Thu, 25 Jun 2015 06:37:57 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE95E1A8873 for <isis-wg@ietf.org>; Thu, 25 Jun 2015 06:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=884; q=dns/txt; s=iport; t=1435239476; x=1436449076; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=pYaLOOthR2tROz3WYQUuZrMmCBTnWe7cxkFEtpSMoLc=; b=ZyJR//G91UIKtEJj1+g71WuDHIohVBr9w4I945EJG7dzZ+S3lbnMXqv5 CkO01w4UQfglJShYjpH+zZFisiu2pRh3DAj/kwYYArswoXTw8aBF9zTSG 1lCw6e6Gmxnms8lz6f/yDJvfKaUj6+CEEdZ7PLSFc6rX30hwDysQaMPgX Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlBQCJA4xV/5FdJa1bgxGBObhhg0VviRk6EgEBAQEBAQGBCoQpOlEBPkInBC6IFKgNphABAQEBAQUBAQEBAQEBG5NugRQFlAUBi1CYOCZjgxeCNYECAQEB
X-IronPort-AV: E=Sophos;i="5.13,677,1427760000"; d="scan'208";a="6510170"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jun 2015 13:37:56 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5PDburu003164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <isis-wg@ietf.org>; Thu, 25 Jun 2015 13:37:56 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.76]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 08:37:55 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: How to handle multiple overlapping SRGB ranges
Thread-Index: AQHQr0wkXCw5I88510e7JcWFLoNcdw==
Date: Thu, 25 Jun 2015 13:37:55 +0000
Message-ID: <96844357-B74E-4685-91F6-D99C7D8106FD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.80.119]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FC3F002A2944344EACC6CE3A89E882C0@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/ID4R7h4Dfx63nQxy4yPa4VLwGTA>
Subject: [Isis-wg] How to handle multiple overlapping SRGB ranges
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 13:38:02 -0000

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 ?

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.

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.

v2.8.10 | Report a Bug | By Email