Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 02 February 2016 12:30 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0F71A8A54 for <spring@ietfa.amsl.com>; Tue, 2 Feb 2016 04:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 QYeJ72OgvaxE for <spring@ietfa.amsl.com>; Tue, 2 Feb 2016 04:30:12 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D891A8A45 for <spring@ietf.org>; Tue, 2 Feb 2016 04:30:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78698; q=dns/txt; s=iport; t=1454416212; x=1455625812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xzzaEVbi1b518du8bbVL1vwmvDfOSAIwZPmE8z5dh1s=; b=ehYNZU5Jy/BJea1kD8+BHfT4H4u9MLXxkLSe1oDuW4pHyEAI60rHrNtO leuhisrBZ+QNTx2fNSuXL0TSGwzCBdpHAXqZC9GLftCL2x3jxazcjORhk cXhON7/X3c69Q83wURFDN4Jw8mSc9gkS5f4ffDwQ/HG5ibJ5Z9eNuvnjX 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CWAgBYoLBW/5ldJa1UCoM6UixBBoJphWqxagENgWQXCoUiSgIcgSk4FAEBAQEBAQGBCoRBAQEBAgEBAQEBCQ4BCBEzBwQHBQcEAgEGAhEBAgEBAQECAhESAwICAiULFAECBggCBAENBQgBEod4CA4Dkg+dE45yAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuFFIM8e4IpgVkGCwEGCSUpgkGBOgWHXYZ3iB0BhUaCbIURgWJKg3iDJoUuhW+EfoNRAR4BAUKCAxmBSGoBiDECBQIXBxZ8AQEB
X-IronPort-AV: E=Sophos;i="5.22,384,1449532800"; d="scan'208";a="232198111"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2016 12:30:08 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u12CU5N0006192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 12:30:06 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 06:30:04 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 2 Feb 2016 06:30:04 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY
Thread-Index: AdFGrZpYeuy+ZVFFQhqjZsVo6KrkgJ7tMoGA4RcwG4CAABUBAIAHsuAAgAA2JgCAABpQgIAAVcog///B3QCAAF3IMIAAd+kAgAAo95CAADhH0IAAMLLAgADUdAD//3SHEP/+Xc0w//vsRGD/9zuwAP/u2ShQ/9wYG4D/uHLMoP9wQwKA/uDoT0D9vCMUAPt2XoqA9u0gKtDtxrdb8NuMeIwAtxkca3A=
Date: Tue, 02 Feb 2016 12:30:04 +0000
Message-ID: <a0059484a7f44f57807031f91cdf296c@XCH-ALN-001.cisco.com>
References: <844C39B6-BC7F-4BE6-95C6-5C1AA16A91B5@cisco.com> <77bddcaf65bf4c2383a25795a52aaf3c@XCH-ALN-001.cisco.com> <40d7a46cac534fa2a1f66ed4fdd1eae3@XCH-ALN-001.cisco.com> <13612_1454403466_56B06F8A_13612_1146_1_3b8ed0c4-7693-4b5b-98bd-315325130dc6@OPEXCLILM7F.corporate.adroot.infra.ftgroup>
In-Reply-To: <13612_1454403466_56B06F8A_13612_1146_1_3b8ed0c4-7693-4b5b-98bd-315325130dc6@OPEXCLILM7F.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.22.20]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/spring/3qPPmMXI-zW2xjYgU6AmUBVIhAE>
Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, Uma Chunduri <uma.chunduri@ericsson.com>, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2016 12:30:21 -0000
Stephane - Thanx for the quick review. Inline. > -----Original Message----- > From: stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > Sent: Tuesday, February 02, 2016 12:58 AM > To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi) > Cc: DECRAENE Bruno IMT/OLN; spring@ietf.org; Uma Chunduri; Henderickx, > Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Hi Les, > > Many thanks for the text proposal. > I agree on most of the proposal expect : > " When > the procedures defined in [SR-MPLS] for mapping global SIDs to > outgoing labels are followed the advertising node is determined to be > incapable of supporting all global SIDs." > > The statement is not true, as if the advertising node has a global SID with PHP > enabled or explicit-null, there is no need of SRGB for installing the label > mapping. > I would rather propose a slight change to align with [SR-MPLS] wording : > " When > the procedures defined in [SR-MPLS] for mapping global SIDs to > outgoing labels are followed the advertising node is determined to be > incapable of supporting MPLS operations for global SIDs." > [Les:] I find the addition of "MPLS operations" redundant. The reference [SR-MPLS] after all is restricted to MPLS operations - as is the use of SRGB. If you feel that the use of EXPLICIT_NULL/IMPLICIT_NULL and its relationship to the use of SRGB (none at all) is not adequately discussed in [SR-MPLS] please propose changes in that draft. I think it best that [SR-MPLS] be the authoritative document in this area. Les > Best regards, > > Stephane > > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Tuesday, February 02, 2016 01:22 > To: Stefano Previdi (sprevidi); LITKOWSKI Stephane SCE/OINIS > Cc: DECRAENE Bruno IMT/OLN; spring@ietf.org; Uma Chunduri; Henderickx, > Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Now that draft-ietf-spring-segment-routing-mpls-03.txt is available, here is > proposed text for draft-ginsberg-spring-conflict-resolution Section 2 which > reflects the conclusions of this thread regarding handling of SRGB > inconsistency: > > "For the set of ranges to be usable the ranges MUST be disjoint. > Sender behavior is defined in various SR protocol drafts such as [SR- > IS-IS] which specify that senders MUST NOT advertise overlapping > ranges. > > Receivers of SRGB ranges MUST validate the SRGB ranges advertised by > other nodes. If overlapping ranges are detected receivers MUST > ignore all advertised SRGB ranges from that node. Operationally the > node is treated as though it did not advertise any SRGB ranges. When > the procedures defined in [SR-MPLS] for mapping global SIDs to > outgoing labels are followed the advertising node is determined to be > incapable of supporting all global SIDs. > > Note that utilization of local SIDs (e.g. adjacency SIDs) advertised > by a node is not affected by the state of the advertised SRGB." > > > Les > > > > -----Original Message----- > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg > > (ginsberg) > > Sent: Wednesday, January 20, 2016 6:04 AM > > To: Stefano Previdi (sprevidi); Stephane Litkowski > > Cc: bruno.decraene@orange.com; spring@ietf.org; Uma Chunduri; > > Henderickx, Wim (Wim) > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > > INCONSISTENCY > > > > Stefano - > > > > Thanx for the proposal - it makes sense to me. > > > > The handling of overlapping SRGB then reduces to following the > procedures > > defined in the to be updated sr-mpls draft for the case where a SID cannot > > be mapped to the (set of) SRGB ranges advertised by the nexthop. This will > > make clear that the PHP case is unaffected by overlapping SRGB ranges. > > > > Once a proposal for the revised sr-mpls draft is available I will propose new > > text for draft-ginsberg-spring-conflict-resolution. This should address the > > concerns raised by Bruno and Stephane. > > > > Les > > > > > > > -----Original Message----- > > > From: Stefano Previdi (sprevidi) > > > Sent: Wednesday, January 20, 2016 5:52 AM > > > To: Stephane Litkowski; Les Ginsberg (ginsberg) > > > Cc: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org; > > > Henderickx, Wim (Wim) > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > > > INCONSISTENCY > > > > > > Hi Stephane, > > > > > > I agree with you. > > > > > > I also noticed that in draft-ietf-spring-segment-routing-mpls we > > > should have > > > (probably) a better description on how to use SRGB and indexes. > > > > > > I propose to update draft-ietf-spring-segment-routing-mpls so that the > > > conflict-resolution draft can point to it when referring to > > > SRGB/index procedures. > > > > > > > > > s. > > > > > > > > > > On Jan 19, 2016, at 9:46 AM, stephane.litkowski@orange.com wrote: > > > > > > > > Hi Les, > > > > > > > > IMO, “treat the sending node as NOT SR-MPLS capable for globally > > > > scoped > > > SIDs” may lead to confusion and let think that only Adj-SID can be used. > > > > “NOT SR-MPLS capable” is really strong, and may prevent the PHP case > > > Bruno was describing. > > > > May be we can add a sentence to precise what the statement means > like > > : > > > “This means that the sending node is not able to process MPLS labels > > > mapped to globally scope SIDs.”. > > > > > > > > > > > > Stephane > > > > > > > > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les > > > > Ginsberg (ginsberg) > > > > Sent: Saturday, January 16, 2016 01:13 > > > > To: Uma Chunduri; DECRAENE Bruno IMT/OLN > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Uma – > > > > > > > > It is true that the neighbor of the dysfunctional node cannot > > > > install > > > outgoing labels for paths via the dysfunctional node. That is > > > precisely the meaning of “treat the sending node as NOT SR-MPLS > > > capable for globally scoped SIDs”. > > > > > > > > This does not mean that “global SID advertisements should be ignored”. > > > And I do not see that it could in any way be interpreted to imply that. > > > > > > > > Please hit the “reset button” and try looking at this with a fresh > > > > perspective. J > > > > > > > > Les > > > > > > > > > > > > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > > > > Sent: Friday, January 15, 2016 3:56 PM > > > > To: Les Ginsberg (ginsberg); bruno.decraene@orange.com > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Les, > > > > > > > > In-line [Uma]: > > > > > > > > -- > > > > Uma C. > > > > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > > > > Sent: Friday, January 15, 2016 12:22 PM > > > > To: Uma Chunduri; bruno.decraene@orange.com > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Uma – > > > > > > > > I have no idea how you translate: > > > > > > > > Receivers of an invalid SRGB MUST ignore the SRGB and treat the > > > > sending > > > node as NOT SR-MPLS capable for globally scoped SIDs. > > > > > > > > into > > > > > > > > Should not consider any global SIDs, because the advertised global > > > > SIDs are not trustworthy any more > > > > > > > > SRGB defines the node-local label space which has been reserved for > > > > use > > > by SR on that node. > > > > [Uma]: …and also the upstream neighboring node to compute and > > > > install > > > the outgoing label J. > > > > > > > > Global SIDs define the index which is to be used into the node > > > > specific > > > SRGBs to map the index into the correct node-specific label. > > > > [Uma]: ..of both advertising node’s own SRGB locally and the SRGB of > > > computed shortest path neighbor. > > > > > > > > While I will do my best to make the language in the draft clear and > > > > unambiguous, > > > > > > > > [Uma]: thx! > > > > > > > > I am frankly at a loss to understand how you concluded that the SRGB > > > related statement says anything whatsoever about SID advertisements. > > > > [Uma]: because of this > > > > “sending node as NOT SR-MPLS capable for globally scoped SIDs” > > > > hence the conclusion of not using the global SIDs!! > > > > > > > > > > > > Les > > > > > > > > > > > > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > > > > Sent: Friday, January 15, 2016 10:13 AM > > > > To: Les Ginsberg (ginsberg); bruno.decraene@orange.com > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Les, > > > > > > > > Thanks. My quick response below [Uma2]: > > > > > > > > -- > > > > Uma C. > > > > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > > > > Sent: Thursday, January 14, 2016 5:28 PM > > > > To: Uma Chunduri; bruno.decraene@orange.com > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Uma – > > > > > > > > Thanx for the response. > > > > Inline. > > > > > > > > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > > > > Sent: Thursday, January 14, 2016 3:34 PM > > > > To: Les Ginsberg (ginsberg); bruno.decraene@orange.com > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Dear Les, Bruno, > > > > > > > > Thanks for a great discussion on this sticky issue. > > > > > > > > Couple of things: > > > > > > > > 1. Les, I support advertising explicit SR capability of the node; > meaning > > > this doesn’t have to be tied to one or more SRGB range advertisements. > > > > Though for example, OSPF draft doesn’t say anything about ‘no srgb > > > ranges’ in SID/Label Range TLV, my vote is to be explicit about it. > > > > I also agree to change IS-IS document to change and to align to the rest. > > > > > > > > [Les:] IN the case of OSPFv2 there is a separate TLV for advertising > > > algorithm support. This can be used to infer SR-MPLS support for local > > > labels for IPv4. There is no language in the OSPFv2 draft which > > > requires SRGB to be sent. > > > > In the case of OSPFv3, SR Forwarding Capabilities are advertised in > > > > the > > > OSPF Router Informational Capabilities TLV. Again there is no > > > requirement to advertise SRGB – so the forwarding capabilities info > > > can be used to infer support for SR-MPLS local SID support. > > > > > > > > If you think the OSPF draft language is not explicit enough I > > > > suggest you > > > make comments to the OSPF-WG list. > > > > > > > > 2. Revised proposal below is good and I agree on - there is no > > > dependency of SRGB for locally scoped ADJ side it should not be > > > effected because of incorrect SRGB. > > > > - I would say making this change to remove support for local ADJ > sids > > > because of incorrect received SRGB for anode is a bigger change for us > > > (E///) at least. > > > > > > > > >2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the > > > sending node as NOT SR-MPLS capable for globally scoped SIDs. > > > > > > > > A-----B----C-----D > > > > > > > > Consider the above network – if you are node A and you are dealing > > > > with a > > > “conflicting range from node D” but valid ranges from node B – you are > > > saying drop all prefixes with global SIDs. > > > > > > > > [Les:] No – no such statement is made. The statement is “treat the > > > > sending > > > node as NOT SR-MPLS capable for globally scoped SIDs.”. The sending > > > node in your example is “D”. No changes are made as regards SR-MPLS > > > support for A, B, C. This in fact is not much different than what you > > > MUST do today even with a valid SRGB – because you have to check > > > whether the given SID is within the (set of) SRGB range(s) advertised > > > by your nexthop. If your nexthop is D then in this example no global > > > SID will map to a valid label in D’s forwarding plane – so C MUST NOT > > > install an outgoing label when forwarding traffic via D. > > > > > > > > [Uma2]: Precisely and I initially expected only node C, which > > > > eventually > > > uses node D’s SRGB recognizes the conflicts in SRGB and consider D is > > ”NOT > > > SR-MPLS” capable. But the above statement doesn’t reflect this: > > > > “Receivers of an invalid SRGB MUST ignore the SRGB” è here D’s SRGB > > > > is > > > received by all nodes and for this example at node A; per this > > > statement it would ignore these SRGB’s during decision process and > > > w.r.t “sending node as NOT SR-MPLS capable for globally scoped SIDs.” > > > Should not consider any global SIDs, because the advertised global > > > SIDs are not trustworthy any more based on the earlier discussions on > this > > thread. > > > > Perhaps as per your response above, you might want to say the > > > “neighboring upstream receivers should not use these invalid SRGB > > > ranges MUST ignore the…”. > > > > > > > > Evidently, the difference here is to abandon the node which is > > > > sending > > > “corrupted SRGBs” (as now its mandatory to have sending side checks) > > > as an SR-MPLS node for global SIDs by entire network or only upstream > > > neighbors which could be installs the labels in the forwarding with > > > these “corrupted SRGBs”. I prefer modified language to reflect the intent > > correctly. > > > > > > > > Hope this helps. > > > > > > > > Les > > > > > > > > > > > > But, I see you are asking this even though outgoing label is > > > > completely > > > governed by node B (which is advertising valid ranges) in this case. > > > Though this is a bigger change and ideally should be applicable to > > > only C , it is ok to me given the consensus on when senders MUST > > > advertise (non-conflicting > > > ranges) and still conflicting range is seen. > > > > > > > > Most of the checks whatever possible for SRGBs, mapping server SID > > > > range > > > conflicts etc. must be prevented locally and this should be mandated > > > (individual protocol/architecture/conflict document) somewhere. > > > However mapping server SID ranges is a completely different beast and > > > can be discussed some other day on how a receiver should handle the > > > conflicts there. > > > > > > > > -- > > > > Uma C. > > > > > > > > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les > > > > Ginsberg (ginsberg) > > > > Sent: Thursday, January 14, 2016 12:53 PM > > > > To: bruno.decraene@orange.com > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Bruno (and everyone) – > > > > > > > > The remaining point to be discussed seems to be whether – when an > > > invalid SRGB is detected by receivers – the offending node should be > > > considered SR-MPLS incapable for both local and global SIDs or whether > > > we should only consider the node MPLS-SR incapable for Global SIDs. > > > The latter proposal has some merit because SRGB is only used in support > of > > global SIDs. > > > However, in order to do this we must insure that all the protocol > > > drafts are consistent with this concept i.e. that SR-MPLS support has > > > two scopes and that the conditions necessary for supporting each of > > > the two scopes are not identical. > > > > > > > > For locally scoped SIDs it is sufficient that the node indicate that > > > > it supports > > > SR-MPLS for specific address families. > > > > For Globally scoped SIDs the node also has to provide a valid SRGB. > > > > > > > > My reading of the existing protocol drafts in this regard is as follows: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-rout > > > > in > > > > g-extensions/ > > > > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-ext > > > > en > > > > sions/ > > > > > > > > OSPF drafts are consistent with the above. > > > > > > > > https://www.ietf.org/id/draft-ietf-idr-bgp-prefix-sid-02.txt > > > > > > > > BGP only has defined support for globally scoped SIDs – so no issue > > > > here > > > either. > > > > > > > > https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06. > > > > txt > > > > > > > > Here there is an issue. Section 3.1 specifies the contents of the > > > > SR- > > > Capabilities Sub-TLV which includes advertisement of both the SR-MPLS > > > support per address-family AND the SRGB. The text states: > > > > > > > > “One or more SRGB Descriptor entries…” > > > > > > > > So currently it is not valid to send the sub-TLV with no SRGB Descriptors. > > > This text would have to be altered to indicate that the SRGB > > > Descriptors MAY be omitted. This could cause backwards compatibility > > > issues with early deployments as a strict interpretation of the draft > > > would cause such a sub- TLV to be rejected. However, given that local > > > SR-MPLS support only is an unlikely case, I think such a change could > > > be acceptable as there should be sufficient time for all existing > > > implementations to be upgraded before such an exceptional case would > > > need to be deployed (if indeed that is ever required). > > > > > > > > Assuming that the IS-IS draft authors and the WG are willing to make > > > > the appropriate change in the IS-IS draft then I provide a revised > > > > definition of how to handle an invalid SRGB below. I ask all the > > > > folks who have already indicated their approval/disapproval of the > > > > previous proposal to review the revised proposal and indicate their > > > > opinion. Of course I also want to encourage folks who have not yet > > > > voiced their opinion to respond as well. J > > > > > > > > Thanx for all the good discussion – I think the proposal is better for it. > > > > > > > > Les > > > > > > > > Revised Proposal: > > > > 1)SRGB configuration is a local matter. Conforming to the > > > > specification > > > requirement of NOT advertising overlapping SRGB ranges is totally > > > within the control of the local node. Misconfigurations can and MUST > > > be detected BEFORE they are advertised. > > > > > > > > 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the > > > > sending > > > node as NOT SR-MPLS capable for globally scoped SIDs. > > > > > > > > 3)Support for locally scoped SIDs is unaffected by the > > > presence/absence/validity of SRGB advertisements. > > > > > > > > > > > > From: bruno.decraene@orange.com > > > [mailto:bruno.decraene@orange.com] > > > > Sent: Thursday, January 14, 2016 12:30 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Les, > > > > > > > > Please see inline [Bruno2] > > > > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > > > > Sent: Thursday, January 14, 2016 12:49 AM > > > > To: DECRAENE Bruno IMT/OLN > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Bruno - > > > > > > > > From: bruno.decraene@orange.com > > > [mailto:bruno.decraene@orange.com] > > > > Sent: Wednesday, January 13, 2016 1:13 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Les, > > > > > > > > Thanks for the summary of your position. > > > > Mine inlined [Bruno] > > > > > > > > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > > > > Sent: Tuesday, January 12, 2016 10:06 PM > > > > To: DECRAENE Bruno IMT/OLN > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Bruno – > > > > > > > > Taking a step back – resummarizing my position: > > > > > > > > 1)SRGB configuration is a local matter. Conforming to the > > > > specification > > > requirement of NOT advertising overlapping SRGB ranges is totally > > > within the control of the local node. Misconfigurations can and MUST > > > be detected BEFORE they are advertised. > > > > [Bruno] Agreed. > > > > > > > > 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the > > > > sending > > > node as NOT SR-MPLS capable. > > > > [Bruno] “Drop all” (SRGB range) is equally safe. I don’t recall that > > > > you > > > provided any argument against it. > > > > > > > > [Les:] In an earlier reply to Stephane I stated: > > > > > > > > <snip> > > > > You are suggesting that a node which is not capable of supporting > > > > SR-MPLS > > > dataplane for prefix-SIDs should still be allowed to support ADJ-SIDs > > > – although it would have to be restricted to local SIDs (ADJ-SIDs can > > > be assigned from the global SID space - just not the most common > > > usage). While you may be right in that such a practice is not > > > explicitly forbidden by any of the specifications, I am struggling to find a > real > > world use case. > > > > > > > > Doing so certainly complicates implementations. Implementations > > > > today > > > verify whether a node supports SR-MPLS before using SR-MPLS > > > advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this > > > logic be enhanced to treat the case where the node has sent an invalid > > > SRGB as if the node is still SR-MPLS capable but for local SIDs only. > > > I don’t deny this could be done – I just don’t understand why. > > > > > > > > <end snip> > > > > [Bruno2] 3 points : > > > > a) Safety/validity: I’m still reading no argument saying that « Drop > > > > All” is less > > > safe than “SR Incapable”. Can we agree on this? > > > > b) Use cases: Local Segments and in particular Adjacency Segments > > > certainly have use cases. Are you arguing this? If not, “Drop All” has > > > the benefit of not dropping the traffic crossing that node using > > > Local/Adjacency segments. More on this next few lines. > > > > c) Implementation complexity: 1) this is difficult to measure hence > > > > agree > > > on. If your implementation were open source, we could probably discuss > > > it more easily. 2)This may be implementation specific. 3) We have > > > already discussed this > > > > > > https://mailarchive.ietf.org/arch/msg/spring/nAoOL8tCF4qXHYK7c2dIu3Xd4 > > > 7 A In short, before using a global SID, existing implementations > > > must also check that this global SID falls within the SRGB. Hence > > > dropping all the SRGB ranges would already be identified by > > > implementation with no changes. > > > > > > > > In subsequent comments no one has indicated that there is such a use > > > case. In the interest of simplicity I am therefore in favor of the > > > “NOT SR-MPLS capable” approach. > > > > [Bruno2] > > > > - I did indicated use case in existing implementations: > > > > > > > > > > https://mailarchive.ietf.org/arch/msg/spring/FuMaSOnwO3WvtmMWT9SzV > > > 8jbT > > > > pE > > > > - In the context of this discussion, one router > > > > implementation/controller > > > would still be able to cross/use the node advertising conflicting SRGB > > > ranges by using a local adjacency segment. You may not want to > > > implement this use case, but I don’t see a reason to forbid this. > > > > - And again, local/adjacency are already defined and implemented, > > > because there were use cases. > > > > > > > > 3)All proposals to use part of the invalid advertisement run the > > > > risk of > > > making the problem worse and are based upon assumptions which > cannot > > > be verified. > > > > [Bruno] This part is about trade-off and opinions. I agree that the > > > consequences of misrouting are more adverse than the one of dropping > > > traffic. In theory, relative probability of occurrence would also need > > > to be taken into account. > > > > I had the impression that we could agree on Drop all, based on a > > > > shared > > > analysis. > > > > > > > > 4)AS there is no valid reason why a node should send an invalid > > > > range (see > > > #1 above) I have no interest in investing analysis time or > > > implementation and test time in “guess work”. > > > > [Bruno] We agree that there is no valid reason and that this is a > > > > case of > > > error. But bug do happens. If we need a consistent behavior across > > > the network, we need to specify the reaction to errors. I personally > > > think that this choice would be better if based on a shared analysis. > > > It bothers me a bit that the editor of the candidate document has no > > > interest in investing analysis time. > > > > > > > > [Les:] I don’t know if I can make you feel more comfortable, but let > > > > me > > > reemphasize why I do not see analysis in this case as worthwhile. > > > > All options which involve using a portion of the invalid > > > > advertisement > > > require us to make assumptions about what we think the node which > > > advertised the invalid range is actually doing when installing labels > > > in its forwarding plane. Nothing about the invalid advertisement can > > > be reliably used to know what the advertising node is doing – nor to > > > predict what behavior is more likely. It is therefore not possible to > > > do a tradeoff analysis which is other than pure guesswork. I don’t > > > actually need to do the analysis to know this. > > > > > > > > Les > > > > > > > > When we start discussing the second topic (SID conflicts) we have a > > > qualitatively different context. There independent configurations are > > > in play – so a single node does not have full control, human error > > > plays a role, and it makes sense to analyze the best resolution strategy. > > > > But in the case of SRGB the local node has full control, human error > > > > can be > > > detected before it is advertised, and there simply is no justification > > > for trying to compensate for an implementation which has clearly shown > > > it is untrustworthy. > > > > [Bruno] “There is simply no justification” is an overstatement. > > > > Looking > > > outside of SR, discussion on error handling in BGP could be found in > > > draft- ietf-grow-ops-reqs-for-bgp-error-handling and RFC 7606. > > > > -- Bruno > > > > > > > > Les > > > > > > > > > > > > From: bruno.decraene@orange.com > > > [mailto:bruno.decraene@orange.com] > > > > Sent: Tuesday, January 12, 2016 9:50 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Les, > > > > > > > > Please see inline [Bruno2] > > > > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > > > > Sent: Tuesday, January 12, 2016 4:38 PM > > > > To: DECRAENE Bruno IMT/OLN > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Bruno - > > > > > > > > From: bruno.decraene@orange.com > > > [mailto:bruno.decraene@orange.com] > > > > Sent: Tuesday, January 12, 2016 3:51 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: spring@ietf.org; Henderickx, Wim (Wim) > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Les, > > > > > > > > Please see inline 1 point below [Bruno] > > > > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > > > > Sent: Tuesday, January 12, 2016 12:41 AM > > > > To: Fedyk, Don; HENDERICKX, Wim (Wim); DECRAENE Bruno IMT/OLN > > > > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Don - > > > > > > > > From: Fedyk, Don [mailto:don.fedyk@hpe.com] > > > > Sent: Monday, January 11, 2016 3:06 PM > > > > To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim); > > > > bruno.decraene@orange.com > > > > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Hi Les > > > > > > > > So you are saying a node that generates inconsistent SRGB > > > > (overlapping > > > ranges) all by itself should be treated Segment routing incapable and > > > this should be easy to detect by any correctly performing neighbor? > > > > [Les:] Yes. Detection is easy – you simply check for overlapping > > > > ranges in > > > the advertisement from an individual node. > > > > What is generating all the discussion is whether we should treat > > > > that node > > > as SR-MPLS incapable (a couple of variants there) or try to massage > > > the received information into a partially usable form. > > > > > > > > This is probably as good a time as any for me to reply to the latter > > proposal. > > > > > > > > All of the “use some of the information” variants (detailed at > > > > length in > > > Bruno’s posts) depend upon the node which sent the inconsistent SRGB > > > information itself performing the same transformation as the receivers. > > > > [Bruno] This is a good technical point to identify. Thanks. I’ll add > > > > it in the > > > text. IINM, among the options being discussed: > > > > Drop all, Drop from conflict, SR incapable do _not_ require any > > > > action on > > > the advertising node. not to mention consistent action with all others > > nodes. > > > > > > > > [Les2:] Drop from conflict makes an assumption that the faulty node > > > > is > > > using the ranges in the order advertised and that the reason the > > > conflict exists is because the later ranges were configured > > > incorrectly. But we don’t know this for certain. For example – the > intended > > set of ranges is: > > > > > > > > [1000, 1099] > > > > [2000, 2099] > > > > > > > > But something gets mangled when formatting the sub-TLV and what is > > > advertised turns out to be: > > > > > > > > [1000, 2099] > > > > [2000, 2099] > > > > > > > > Using drop from conflict assumes you can use SIDs 0 – 1099 safely, > > > > but in > > > fact SIDs greater than 99 will use a label that the faulty node (which > > > is using the first set of ranges above) is NOT using for SR. > > > > > > > > This looks less egregious than other options only because the > > > > assumption > > > that the first range which is advertised is correct seems “reasonable” > > > or “likely” – but in fact we don’t know that. > > > > > > > > [Bruno2] Yes, and I have updated the text in my document to include > > > > your > > > point.. But I don’t think it’s about « reasonable” or “likely”. In my > > > view, it’s about trusting (or not) a received data which is correct > > > from both a syntax and semantic perspective. > > > > We could define an option which would be dropping before the > conflict. > > > Would that make a difference for you? > > > > Because, I can equally build an example where your proposition would > > > > be > > > erroneous. e.g. > > > > the intended set of ranges is: > > > > [1000, 1099] > > > > [2000, 2099] > > > > > > > > But something gets mangled when using formatting the sub-TLV and > > > > what > > > is advertised turns out to be: > > > > [1000, 1199] > > > > [2000, 2099] > > > > > > > > You believe you can use SID 110 based on the assumption that the > > > > ranges > > > which are advertised are correct, but in fact you don’t know that. > > > > > > > > And if we don’t believe in data which looks like correct from both a > > > > syntax > > > and semantic perspective, we should stop using protocols. > > > > > > > > That being said, I think we now have identified the key point of the > > > > discussions. If so, now it would be about making a trade-off between > > > > Traffic dropping or mis-routing. (as personally I see > > > > “implementation complexity” being a significant point, compared > > > > these 2.) > > > > > > > > -- > > > > > > > > Drop the conflicting one, Merge, Merge and re-order _do_ require a > > > > new > > > behavior on the advertising node, consistent with all others nodes. > > > > > > > > [Les:] Agreed. > > > > > > > > But there is a higher order issue here for me – which is that all > > > > options > > > other than “Drop all” variants have to make an assumption about the > > > faulty node behavior which cannot be verified – which means the > > > attempt to minimize the damage may actually do further harm. This is > > > not acceptable to me. > > > > > > > > Les > > > > > > > > Please comment if you disagree. > > > > -- Bruno > > > > > > > > This to me is a non-starter. You have a node which has a bug in its > > > implementation. Trusting that the node will recognize that it has > > > sent invalid info and needs to transform it when using it internally isn’t > > reasonable. > > > Whether the bug which caused invalid info to be sent also affects the > > > use of that information internally is something you simply have no way to > > know. > > > Basing the behavior of the rest of the network on that assumption > > > isn’t reasonable to me – attempts to determine which data > > > transformation might yield “better” results is pure guesswork since > > > you cannot rely on a buggy implementation behaving in a predictable > way. > > > > > > > > Les > > > > > > > > > > > > Don > > > > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les > > > > Ginsberg (ginsberg) > > > > Sent: Monday, January 11, 2016 5:37 PM > > > > To: Fedyk, Don; HENDERICKX, Wim (Wim); > bruno.decraene@orange.com > > > > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org > > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Folks – > > > > > > > > This thread is about SRGB inconsistency. SRGB inconsistency is an > > > > INTRA- > > > node issue. There is no SRGB conflict issue between nodes. > > > > > > > > There will be a separate thread about SID conflict issues – where > > > > inter- > > > node conflicts certainly are possible – but that is NOT what we are > > > discussing in this thread. > > > > > > > > Perhaps some folks would like to revise their responses with this in > mind? > > > > > > > > Les > > > > > > > > > > > > From: Fedyk, Don [mailto:don.fedyk@hpe.com] > > > > Sent: Monday, January 11, 2016 1:41 PM > > > > To: HENDERICKX, Wim (Wim); bruno.decraene@orange.com > > > > Cc: Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org; > > > > LITKOWSKI Stephane SCE/OINIS > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Hi Wim > > > > > > > > If I understand your Option 1) it can occur, for example, if two > > > > nodes that > > > have a conflicting SRGB but they are not directly connected and as > > > such there can be a race condition where they advertise SRGB conflict at > > roughly the > > > same time. So nodes in the middle have to decide who wins. (If that is > the > > > case, that is the same issue we had in SPB for certain conflicts and > > > the solution was to use NodeID as a tie breaker to decide which node > > > wins.) In the SRGB case the loosing Node would also receive the > > > winning nodes SRGB and would “know” there is a conflict and it lost. > > > It is true that the looser could have had the SRGB established for a > > > long time and suddenly become Segment Routing incapable because of a > > > higher priority node’s conflicting config. However I think that is > > > the nature of this situation SRGB information it must be consistent. > > > The thing to make sure of is that any SRGB configuration can be > > > relatively easily migrated to a non-conflicting range and a > > > configuration model that does not make it easy to accidentally create > SRGB > > conflicts into an existing network. > > > > > > > > Not sure I follow your option 2 but option 1 can be easy to > > > > determine > > > winners and losers (not right and wrong J ). > > > > > > > > Cheers, > > > > Don > > > > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > > > > HENDERICKX, Wim (Wim) > > > > Sent: Monday, January 11, 2016 3:07 PM > > > > To: bruno.decraene@orange.com > > > > Cc: Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org; > > > > LITKOWSKI Stephane SCE/OINIS > > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > I believe we agree to minimise the network impact when SRGB data is > > > inconsistent. > > > > Option 1 is we ignore a advertisements of some nodes. The main issue > > > > I > > > see with this is determining who is right/wrong. Implementation is > > > rather easy, but you will impact traffic from certain nodes in some > > > case as outlined below. > > > > Option 2 is you try to disseminate something out of the information > > > > and try > > > to determine a consistent behaviour across all node. Implementation is > > > more difficult, but I believe there is more coverage/chances to meet > > > the overall objective. > > > > > > > > My 2 cents. > > > > > > > > From: Bruno Decraene <bruno.decraene@orange.com> > > > > Date: Monday 11 January 2016 at 17:53 > > > > To: Wim Henderickx <wim.henderickx@alcatel-lucent.com> > > > > Cc: Martin Horneffer <maho@nic.dtag.de>, "Les Ginsberg (ginsberg)" > > > > <ginsberg@cisco.com>, "spring@ietf.org" <spring@ietf.org>, Stephane > > > > Litkowski <stephane.litkowski@orange.com> > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Hi Wim, > > > > > > > > I read that you are pointing out the difficulty to identify the > inconsistency. > > > > If so, this point is common to all options being discussed. > > > > > > > > I may be missing some of your points. This thread is about > > > > inconsistency in > > > the SRGB ranges advertised by _one_ node. I’m not sure to see your > > > “startup scenario” nor the “merge network scenario”. Could you please > > > elaborate? > > > > > > > > Thanks, > > > > Bruno > > > > > > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > lucent.com] > > > > Sent: Wednesday, January 06, 2016 8:19 PM > > > > To: DECRAENE Bruno IMT/OLN > > > > Cc: Martin Horneffer; Les Ginsberg (ginsberg); spring@ietf.org; > > > > LITKOWSKI Stephane SCE/OINIS > > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > If you avoid an inconsistency in an SRGB announcement there is > > > > multiple > > > scenario’s in which you determine who is right/wrong: > > > > • Assume you are in a startup scenario, it is very hard to > > > > determine > > > who is consistent and who is not > > > > • If you are in a running network and you add a new node or have a > > > different config on 1 node, you can determine it > > > > • If you merge a network and the config is wrong in one part but > > > > not > > > in the other part of the network. > > > > > > > > I see this strategy work in some case but in others I see challenges > > > > to determine what is right and what is wrong, hence my question > > > > > > > > From: Bruno Decraene <bruno.decraene@orange.com> > > > > Date: Wednesday 6 January 2016 at 19:03 > > > > To: Wim Henderickx <wim.henderickx@alcatel-lucent.com> > > > > Cc: Martin Horneffer <maho@nic.dtag.de>, "Les Ginsberg (ginsberg)" > > > > <ginsberg@cisco.com>, "spring@ietf.org" <spring@ietf.org>, Stephane > > > > Litkowski <stephane.litkowski@orange.com> > > > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Hi Wim, > > > > > > > > Many thanks for taking part in the discussion. > > > > Could you please elaborate? e.g. what do you mean by ”who” and > > “wrong” > > > on what? > > > > I could see multiple interpretations, but it would probably be > > > > faster if you > > > elaborate by yourself. > > > > > > > > Thanks > > > > -- Bruno > > > > > > > > From:spring [mailto:spring-bounces@ietf.org] On Behalf Of > > > > Henderickx, Wim (Wim) > > > > Sent: Tuesday, January 05, 2016 7:41 PM > > > > To: Martin Horneffer; Les Ginsberg (ginsberg); spring@ietf.org; > > > > LITKOWSKI Stephane SCE/OINIS > > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > My main question on the proposal is how do we tell who is right and > > > > who is > > > wrong? > > > > > > > > From: spring <spring-bounces@ietf.org> on behalf of Martin Horneffer > > > > <maho@nic.dtag.de> > > > > Date: Tuesday 5 January 2016 at 13:05 > > > > To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "spring@ietf.org" > > > > <spring@ietf.org>, Stephane Litkowski > > > > <stephane.litkowski@orange.com> > > > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > > > SRGB INCONSISTENCY > > > > > > > > Hello Les, Acee, Stephane, everyone, > > > > > > > > happy new year! > > > > > > > > From an operator's (carrier's) point of view I clearly and strongly > > > > support > > > this alternative solution: Treat an inconsistent set of SRGB > > > announcements as broken and ignore it. > > > > > > > > - It is the simplest solution. > > > > - It only affects traffic of the badly configured and implemented router. > > > > - It gives a clear indication to the operator where they have to > > > > repair > > > something. > > > > > > > > With respect to Stephane's comments: > > > > - I would also support a repetition or clarification that an > > > > inconsistent set of > > > SRGB annoucements is broken. > > > > - No strong opinion from my side as how to define the offending > > > > node as > > > non-SR-capable as I don't see any use case for nodes with only > > > adjacency SIDs. > > > > > > > > Best regards, > > > > Martin > > > > > > > > > > > > Am 04.01.16 um 06:55 schrieb Les Ginsberg (ginsberg): > > > > One of the topics discussed in > > > > https://datatracker.ietf.org/doc/draft- > > > ginsberg-spring-conflict-resolution/ is how to handle inconsistent > > > SRGB advertisements from a given node. > > > > > > > > The draft defines one possible solution -from Section 2: > > > > > > > > " Each range is examined in the order it was advertised. If it does > > > > not overlap with any advertised range which preceded it the > > > > advertised range is used. If the range overlaps with any preceding > > > > range it MUST NOT be used and all ranges advertised after the first > > > > encountered overlapping range also MUST NOT be used." > > > > > > > > This is one instance of a class of solutions which attempt to make > > > > use of > > > part of the advertisements even when there is some inconsistency > > > (overlap) in the set of SRGB ranges received. A more complete > > > discussion of this class of solutions can be seen in > > > https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many > > > thanx to Bruno for writing this. > > > > > > > > However, there is an alternative solution which was suggested > > > > (notably by > > > Acee Lindem) after the draft was written. This alternative is to > > > ignore the entire set of SRGB advertisements and treat the problematic > > > router as if it were not SR MPLS capable. This alternative was > > > discussed during the presentation in SPRING WG at IETF94 (see > > > https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide > > #3). > > > It is also discussed in Bruno's post > > > (https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see > > > Section 2.2). > > > > > > > > The basis of the alternative solution is that a correct > > > > implementation should > > > never allow inconsistent SRGB ranges to be successfully configured > > > (let alone advertised). So this is not a case of a misconfiguration – > > > it is a case of a defective implementation. It then seems appropriate > > > to put the onus on the originating router to only send valid SRGB > > > advertisements rather than forcing all the receivers to try to > > > "correct" the invalid information in some consistent way. This has a > number > > of advantages: > > > > > > > > 1. It is by far the simplest to implement > > > > 2. It isolates the router which is untrustworthy > > > > 3. As the problem can only occur as a result of a defective > > > implementation the behavior of the originating router is unpredictable > > > – it is therefore safer not to use the information > > > > > > > > It is worth noting that since the invalid advertisement is the > > > > result of some > > > sort of defect in the originating router’s implementation, it is not > > > safe to assume that the source will actually be using the advertised > > > SRGB in a manner consistent with the selective choice made by the > > receiving routers. > > > > > > > > I therefore propose that the above quoted text from > > > https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolu > > > tion/ > > > be replaced with the following: > > > > > > > > “The set of received ranges is examined . If there is overlap > > > > between any > > > two of the advertised ranges the entire SRGB set is considered invalid > > > and is ignored. > > > > The originating router is considered to be incapable of supporting > > > > the SR- > > > MPLS forwarding plane. Routers which receive an SRGB advertisement > > > with overlapping ranges SHOULD report the occurrence.” > > > > > > > > Comments? > > > > > > > > Les > > > > > > > > > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > ___________________________________________________ > > > > > > > > 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 > > > > spring@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > __________________________________________________________ > __________________________________________________________ > _____ > > 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] draft-ginsberg-spring-conflict-resolutio… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… Acee Lindem (acee)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… Martin Horneffer
- Re: [spring] draft-ginsberg-spring-conflict-resol… Henderickx, Wim (Wim)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… Henderickx, Wim (Wim)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… HENDERICKX, Wim (Wim)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Fedyk, Don
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Fedyk, Don
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… AISSAOUI, Mustapha (Mustapha)
- Re: [spring] draft-ginsberg-spring-conflict-resol… HENDERICKX, Wim (Wim)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… HENDERICKX, Wim (Wim)
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… HENDERICKX, Wim (Wim)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… John E Drake
- Re: [spring] draft-ginsberg-spring-conflict-resol… Jeff Tantsura
- Re: [spring] draft-ginsberg-spring-conflict-resol… Mach Chen
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… Stefano Previdi (sprevidi)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Uma Chunduri
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… Peter Psenak
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Uma Chunduri
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Uma Chunduri
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… Uma Chunduri
- Re: [spring] draft-ginsberg-spring-conflict-resol… Uma Chunduri
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… Stefano Previdi (sprevidi)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… Les Ginsberg (ginsberg)
- Re: [spring] draft-ginsberg-spring-conflict-resol… stephane.litkowski
- Re: [spring] draft-ginsberg-spring-conflict-resol… bruno.decraene