Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> Mon, 12 January 2015 15:13 UTC
Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20721AC3AB; Mon, 12 Jan 2015 07:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.61
X-Spam-Level:
X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 HqOJYVCpO9Ka; Mon, 12 Jan 2015 07:13:16 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384F21AC39D; Mon, 12 Jan 2015 07:13:15 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1657D17BD56F; Mon, 12 Jan 2015 15:13:10 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t0CFDCdd013526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 16:13:12 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 16:13:12 +0100
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Rob Shakir <rjs@rob.sh>
Thread-Topic: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
Thread-Index: AQHQLj+19rH0/A1Xy0ObHnHUPdPr+5y8G+CAgAARysCAAB57gP//8qQAgABZPQA=
Date: Mon, 12 Jan 2015 15:13:12 +0000
Message-ID: <D0D9684F.11A85E%wim.henderickx@alcatel-lucent.com>
References: <D0CF6C5B.1B6DD%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA26EF@xmb-aln-x02.cisco.com> <D0D00E58.1B720%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA29A2@xmb-aln-x02.cisco.com> <D0D02765.1B76C%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA2A4F@xmb-aln-x02.cisco.com> <BY1PR0501MB13812B36C2020C3AC3072641D5580@BY1PR0501MB1381.namprd05.prod.outlook.com> <F3ADE4747C9E124B89F0ED2180CC814F4EEA4F1A@xmb-aln-x02.cisco.com> <28823_1420641858_54AD4642_28823_8441_1_9E32478DFA9976438E7A22F69B08FF920C765C15@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1868F3A4-A4E2-4504-A749-582305FA31B4@rob.sh> <18651_1421050415_54B3822F_18651_14831_1_9E32478DFA9976438E7A22F69B08FF920C76D265@OPEXCLILM34.corporate.adroot.infra.ftgroup> <53C29892C857584299CBF5D05346208A0EB01975@PEXCVZYM11.corporate.adroot.infra.ftgroup> <21149_1421052896_54B38BE0_21149_1085_1_86923dca-49c3-4745-881c-116ec27cb9f2@OPEXCLILH02.corporate.adroot.infra.ftgroup> <D0D9633B.11A80B%wim.henderickx@alcatel-lucent.com> <13987_1421060024_54B3A7B8_13987_19542_1_3b33983a-7671-4df1-a1ac-52b83d8162a0@OPEXCLILH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <13987_1421060024_54B3A7B8_13987_19542_1_3b33983a-7671-4df1-a1ac-52b83d8162a0@OPEXCLILH02.corporate.adroot.infra.ftgroup>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C2107E7835282C4E956E55376EDF387C@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Fe8LrcR1VvZT5KLv9BEMPGmzfgg>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-segment-routing-extensions@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" <draft-ietf-isis-segment-routing-extensions@tools.ietf.org>
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 15:13:24 -0000
I understand that certain vendors will not easily accommodate this, so I understand we need a solution like you suggest or support a combination of Adj-SID/Node-SID based on where you want to avoid the rerouting. On 12/01/15 11:53, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com> wrote: >Very good point, in our case, today we have up to 15 strict hops for TE >tunnels. >When we will introduce interdomain, it will bring more. > >-----Original Message----- >From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >Sent: Monday, January 12, 2015 11:45 >To: LITKOWSKI Stephane SCE/IBNF; DECRAENE Bruno IMT/OLN; Rob Shakir >Cc: ospf@ietf.org; spring@ietf.org; >draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >isis-wg@ietf.org; >draft-ietf-isis-segment-routing-extensions@tools.ietf.org >Subject: Re: [OSPF] [Isis-wg] Mail regarding >draft-ietf-ospf-segment-routing-extensions > >How many hops do we want to support in these scenario’s realistically? >This might help in determining the options > >On 12/01/15 09:54, "stephane.litkowski@orange.com" ><stephane.litkowski@orange.com> wrote: > >>Hi Bruno, >> >>Using TTL may work or not. Backup path does not mean that you will >>defacto have more hops. Metric of backup path could be higher but >>number of hops equal or smaller. >> >>I created a new thread on SPRING WG list to discuss the different >>options. >> >>Thanks ! >> >>-----Original Message----- >>From: DECRAENE Bruno IMT/OLN >>Sent: Monday, January 12, 2015 09:49 >>To: LITKOWSKI Stephane SCE/IBNF; Rob Shakir >>Cc: isis-wg@ietf.org; >>draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>ospf@ietf.org; >>draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>Subject: RE: [OSPF] [Isis-wg] Mail regarding >>draft-ietf-ospf-segment-routing-extensions >> >>Hi, >> >>2 cents inlined >> >>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of > >>> stephane.litkowski@orange.com >>> >>> Hi, >>> >>> After discussing a lot with Les offline, we almost found an agreement >>> on the understanding of this use case and possible relationship with >>> unprotected SIDs. >>> Use case : >>> Creation of a SR TE tunnel which is unprotected. Protection may be >>> provided end to end using for example two disjoint paths. >>> Controller based or ingress based tunnel setup. >>> >>> It seems clear now that using ONLY unprotected SIDs does not solve >>>the issue as when a link fails, convergence will happen, and nodes >>>that are near the failure may reroute a NodeSID Algo 0 used within >>>the TE stack before Ingress or controller recomputes the new path >>>fitting constraints. So there may be transient situations where the >>>path does not fit constraints anymore. >>> Based on this, introducing "NON PROTECTED" NodeSID does not help in >>>solving this transient situation. >>> >>> Now, as I explained, IMO, it's possible to introduce end to end OAM >>> on top on the SRTE to bring the LSP down as soon as there s something >>> wrong on the path. A Holddown timer can be used to keep LSP down >>> until convergence happens at Ingress or Controller. But introducing >>> such OAM and holddown and coupled with relations with IGP may also be >>> complex and there is a chance that it does not solve the issue. In >>> case of protected NodeSID used, OAM will not work, because switchover >>> time will be too small. Using OAM , defacto requires path with no >>>protection. >>> So unprotected SID+OAM may solve the use at the price of some >>> complexity and possibly not solving 100% of the cases. >>> >>> To conclude : >>> We need to solve this use case and we need to find another elegant, >>> simple and scalable solution for this. >>> >>> Possible existing solutions : >>> - Use Adj-SID only => does not sounds good as there will be an impact >>> of stack depth => Path compression necessary >>> - Use binding TLV and create some new Node-SID corresponding to a set >>> of Adj-SID => This introduces more states within the network (how >>> many >>> ?) >>> - Anything else ? >> >>Combining Adj-SID and Node-SID with a very restricted TTL (to expire on >>the backup path) may be able to avoid IGP rerouting of this LSP. >> >>/Bruno >> >> >>> Best regards, >>> >>> Stephane >>> >>> >>> -----Original Message----- >>> From: Rob Shakir [mailto:rjs@rob.sh] >>> Sent: Thursday, January 08, 2015 10:52 >>> To: LITKOWSKI Stephane SCE/IBNF >>> Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter >>> Psenak (ppsenak); >>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes >>> Gredler; ospf@ietf.org; isis-wg@ietf.org >>> Subject: Re: [Isis-wg] [OSPF] Mail regarding >>> draft-ietf-ospf-segment-routing- extensions >>> >>> Stephane, >>> >>> If we think about the “MUST NOT be protected” case that you mention. >>> Let’s assume that we have a service that is performance sensitive, >>> such that we want to take a particular path through the network - and >>> that we use Node- SIDs like you say. >>> >>> If we assume that the requirement is for A-B-C-D-E path below. The >>> node SID for E points via C-D-E and hence is used for stack >>> compression like you >>> say: >>> >>> A -- B -- C -- D -- E >>> | / >>> --- Q --- >>> >>> In your envisaged behaviour, C does not protect the Node-SID for E. >>> In the case of the C-D link failure, then the “preferred” behaviour >>> is that C now drops traffic towards this destination. However, C does >>> not remove the FIB entry for the Node-SID for E, it’s actually just >>> now known via Q. At this point, A can forward with exactly the same >>> stack, and the packet takes a new A-B- C-Q-E path, which is >>> non-conformant with the performance requirement of the service. >>> >>> In terms of what C does with its FIB, does it simply not use C-Q-E >>> during the failure, but post-reconvergence use it anyway? If so, why >>> not use C-Q-E during the failure - because the service is always >>> going to non-conformant to the performance requirement? >>> >>> With an Adj-SID, it makes sense, because essentially unless that >>> adjacency is available, then there is no alternate path for the SID >>> that will be taken - so traffic never hits a non-conformant path. >>> >>> Practically, if I can’t tell a customer that the path taken will >>>definitely be A-B- C-D-E, and it may rather go via C-Q-E at some point >>>following convergence [until the head-end calculates that such a >>>change had happened - either a link outage, or a metric change - and >>>stops using the label stack], then there’s little problem of having >>>the traffic go via C-Q-E during protection. >>> >>> For the disjoint case, the consideration that one has to make is: >>> * are alternative SPF paths for a particular Node-SID actually still >>>conformant with the disjointness requirement? How many simultaneous >>>failures does one require to violate constraints. For example, in a >>>dual-plane core network, then if the requirement is disjointness at >>>the IP level, then we may need to lose connectivity entirely within >>>the plane before it is preferable to “hop” to another plane. In this >>>case, using an alternative SPF path for the Node-SID is actually not a >>>problem for disjointness. >>> * does the application prefer losing an entire path to having some >>>risk of the services being shared fate until the re-optimisation? >>> >>> From the work that we’ve looked at thus far, I have not yet seen a >>> case where I absolutely MUST NOT use an alternate shortest path for a >>> Node-SID and hence don’t require protection at a practical level. >>> >>> Stack depth is definitely going to be something that we need to >>>consider - to me, where we have centralised controller - actions such >>>as dynamically created forwarding-adjacency LSPs which allow >>>“expansion” of one segment into a set of segments within the path are >>>attractive as a solution where one needs to have explicit routing of >>>traffic for TE purposes. >>> >>> Does this make sense, or do you see the use case that we’re >>> addressing here differently? >>> >>> Cheers, >>> r. >>> >>> >>> > On 7 Jan 2015, at 09:44, stephane.litkowski@orange.com wrote: >>> > >>> > Hi, >>> > >>> > I'm coming into this long thread and I tried to read all the >>> > exchange but I may be missed some lines :) >>> > >>> > But here is my opinion on this subject. >>> > I think the point from Shradda is valuable in case of Traffic >>> > Engineering with >>> Segment Routing, especially with a central controller. >>> > >>> > Today in TE networks, we are selling some disjoints paths to >>> > customer that >>> MUST NOT be protected (SDH like services). It would be good to >>> reproduce the same thing with SR-TE. >>> > >>> > Now, current encoding permits to advertise that a specific Adj-SID >>> > is >>> protected or not (as already mentioned, this does not say that a >>> protection really exists ..., in case of LFA protection , there may >>> be no FRR path for this adj-SID despite of the protection flag set). >>> > We pretty know that it would not be possible in all case to use >>> > only Adj-SID >>> for a TE tunnel (due to label stack depth), so we need to introduce >>> stack compression using SPT segments and node-SID. >>> > So to reply on Rob's comment, on RSVP-TE tunnels with looses hops >>> > that >>> does not request protection : yes for RSVP, it does not make sense to >>> me, but for SR, due to stack compression, it will be needed. >>> > >>> > If we look at a network, where TE is managed by a central >>> > controller, how >>> the controller can ensure that the node-SID used is protected or not >>> (as for Adj-SID, I mean protection requested, not protection >>> installed). I see two ways : >>> > * Use two SIDs attached to the same prefix and add a flag to >>> > prevent >>> automatically all nodes to compute a protection for one of the SID. >>> The flag does not really force nodes to compute a protection. Each >>>node will still require local configuration for protection, but the >>>flag will permit to exclude some prefixes for protection (overriding >>>local policy). >>> > >>> > * Use two prefixes on each node , prefixes are marked with tags >>> (admin-tags) : "protection tag" and "non protection tag". Each router >>>is configured using LFA policies to not compute protection for >>>prefixes having "non protection tag" AND add knowledge to the >>>controller to use only "non protection tag" prefixes to compress non >>>protected path. >>> > >>> > >>> > Best Regards, >>> > >>> > Stephane >>> > >>> > -----Original Message----- >>> > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les >>> > Ginsberg (ginsberg) >>> > Sent: Monday, January 05, 2015 16:59 >>> > To: Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); >>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes >>> > Gredler >>> > Cc: ospf@ietf.org; isis-wg@ietf.org >>> > Subject: Re: [Isis-wg] [OSPF] Mail regarding >>> > draft-ietf-ospf-segment-routing-extensions >>> > >>> > Shraddha - >>> > >>> > As Jeff has already mentioned, the case you are concerned about can >>> > be handled using LFA selection strategies discussed in >>> > http://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ >>> > And it is a far better solution since it allows the traffic of >>> > interest to be >>> protected => less traffic interruption. >>> > >>> > Les >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: Shraddha Hegde [mailto:shraddha@juniper.net] >>> > Sent: Monday, January 05, 2015 12:49 AM >>> > To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak >>> > (ppsenak); >>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes >>> > Gredler >>> > Cc: ospf@ietf.org; isis-wg@ietf.org >>> > Subject: RE: [OSPF] [Isis-wg] Mail regarding >>> > draft-ietf-ospf-segment-routing-extensions >>> > >>> > Les, >>> > >>> > Pls consider a case when the post convergence path goes through a >>> different node and is well provisioned. >>> > >>> > --------G------- >>> > | | >>> > A----B----C----D >>> > | | >>> > E----F >>> > >>> > When the link between B & C goes down, we don’t want to divert the >>> traffic via B-E-E-F-C because it is not well provisioned for the >>>service. >>> > The post convergence path is A-G-D which is well provisioned. >>> > In this case it makes sense to simply avoid protection for the >>> > service as the >>> nature of the service is such that it can be disconnected and >>> reconnected without impacting the end user of the service. >>> > >>> > >>> > The post convergence paths need to be provisioned at least for one >>> > failure >>> if that is not the case then the service will remain down >>> Irrespective of the technology used. >>> > >>> > >>> > Rgds >>> > Shraddha >>> > >>> > -----Original Message----- >>> > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] >>> > Sent: Monday, January 05, 2015 12:07 PM >>> > To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); >>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes >>> > Gredler >>> > Cc: ospf@ietf.org; isis-wg@ietf.org >>> > Subject: RE: [OSPF] [Isis-wg] Mail regarding >>> > draft-ietf-ospf-segment-routing-extensions >>> > >>> > Pushpasis - >>> > >>> > Inline. >>> > >>> > -----Original Message----- >>> > From: Pushpasis Sarkar [mailto:psarkar@juniper.net] >>> > Sent: Sunday, January 04, 2015 10:13 PM >>> > To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak >>> > (ppsenak); >>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes >>> > Gredler >>> > Cc: ospf@ietf.org; isis-wg@ietf.org >>> > Subject: Re: [OSPF] [Isis-wg] Mail regarding >>> > draft-ietf-ospf-segment-routing-extensions >>> > >>> > Hi Les, >>> > >>> > >>> > On 1/5/15, 11:23 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> >>> wrote: >>> > >>> >> Pushpasis - >>> >> >>> >> The key point is that the proposal does not have any lasting >>> >> impact on traffic flow. A simple topology should suffice to >>>illustrate this. >>> >> >>> >> >>> >> A----B----C----D >>> >> | | >>> >> E----F >>> >> >>> >> (All links have the same cost) >>> >> >>> >> Suppose we wish to have traffic entering at A flow along the path >>> >> A-B-C-D >>> >> - but if the link B---C fails we do NOT want traffic to take the >>> >> path B--E--F--C. >>> >> >>> >> You propose to have C advertise an address with two node-sids - >>> >> one which allows protection - call it C(P) - and one which does >>> >> NOT allow protection - call it C(NP). >>> > [Pushpasis] No. My proposal is for D to advertise two node sids, D1 >>> > with NP >>> set to 0 and D2 with NP set to 1. Applications on that do not need B, >>> or C to protect the A-B-C-D path will use D2. B and C will not >>> install backup paths for D2. Other apps can use D1 as they are >>> supposed to do otherwise. Wether to protect D1 or not is a local >>>decision of B and C. >>> > Hope I could clarify enough :) >>> > >>> > [Les:] Whether we talk about C or D doesn’t matter. As you point >>> > out >>> below the issue you are concerned with is the FIB update time on the >>> intermediate nodes relative to the recomputation on the ingress node. >>> > >>> >> >>> >> If the label stack specifies C(NP) - then while the link B--C is >>> >> UP everything works as desired (primary path to C(NP) on Node B is >>> >> via link B-C). >>> >> However, when the link B--C goes down, the network will reconverge >>> >> and in a modest amount of time the new primary path to C(NP) on >>> >> node B will be via link B-E. >>> > [Pushpasis] Yes agreed. But only applications on A will be >>> > injecting traffic >>> using D2. Once the B-C link-down event reaches router A will stop >>>injecting traffic using D2. A path re-compute will be triggered on A. >>> Yes I agree that if B converges D2 (not FRR) before A re-compute, >>>there is still chance that some small amount of traffic is sent over >>>A-B-E-F-C-D. >>> > >>> > [Les:] Well yes - the key point is that you cannot guarantee the >>> > timing of >>> when B (for example) will reconverge relative to when the ingress >>>node A decides to reroute/drop the D2 traffic. Given that B is closer >>>to the failure it is quite likely that B will respond more quickly >>>than A >>> - and of course there are many other variables which could affect the >>>relative response time of A and B. So the sole benefit of what you >>>propose seems to be that in some cases you MIGHT not send as much >>>traffic to D2 via the undesired links. >>> > >>> > At this point I think you would do well to look at the existing >>> > solutions - as >>> well as Jeff's post on this thread which provides an excellent >>> framework for thinking about solutions. We do have ways of addressing >>> this problem and doing so far more robustly than what you are >>> proposing. The ROI for what you propose is quite low. For my part I >>> don’t think what you propose is a good idea. >>> > >>> > Les >>> > >>> >> >>> >> The existence of C(NP) therefore only affects traffic flow during >>> >> the reconvergence period i.e. if we assume B did NOT install a >>> >> repair path for C(NP) traffic will be dropped only until a new >>> >> primary path is calculated. I don’t see the value in this. >>> >> >>> >> As a (somewhat dangerous) aside, the functionality you are looking >>> >> for is more akin to "not-via" as defined in RFC 6981 - though I am >>> >> quick to add that I am NOT proposing to pursue that. :-) But >>> >> reading that RFC might give you more insight into why simply >>> >> setting "don't protect" for a prefix isn't useful for the purpose >>>you have in mind. >>> >> >>> >> Les >>> >> >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: Pushpasis Sarkar [mailto:psarkar@juniper.net] >>> >> Sent: Sunday, January 04, 2015 8:34 PM >>> >> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak >>> >> (ppsenak); >>> >> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >> draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes >>> >> Gredler >>> >> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >> Subject: Re: [OSPF] [Isis-wg] Mail regarding >>> >> draft-ietf-ospf-segment-routing-extensions >>> >> >>> >> Hi Les, >>> >> >>> >> Please find comments inline.. >>> >> >>> >> Authors, >>> >> >>> >> Here is my proposal. Please let me know if this sounds reasonable >>> >> or >>>not. >>> >> >>> >> - A new ŒNo-Potection-Required¹ or ŒNP¹ flag be added to the >>> >> Prefix-SID Sub-TLV/TLV. Setting this flag means none of the >>> >> transit routers should try to protect this node-segment. >>> >> - Let nodes advertise two node-sid-index each (per >>> >> address-family), one without and one with ŒNP¹ flag set. For >>> >> node-sid advertised with ŒNP¹ flag 0, routers same behave the same >>> >> way as today. But when they receive a node-sid with ŒNP¹ flag set, >>> >> they avoid/skip finding a backup for that segment. >>> >> - Finally ingress servers or TE-applications may use these >>> >> 'node-sids with NP-flag set¹ for use cases where it is better to >>> >> drop traffic on topology outages rather than diverting it to some >>> >> other paths. For such cases ingress router or TE-applications >>> >> should look for node-sids with ŒNP¹ flag set and not the regular >>> >> node-sids. For all other normal use cases(including L3VPN/6VPE >>> >> etc) traffic should be carried using node-sid without ŒNP‹flag set. >>> >> >>> >> Thanks and Regards, >>> >> -Pushpasis >>> >> >>> >> On 1/5/15, 3:37 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> >>> wrote: >>> >> >>> >>> Pushpasis - >>> >>> >>> >>> I don't agree. >>> >>> >>> >>> The use of one node-sid vs another has nothing whatever to do >>> >>> with the request Shraddha has made i.e. should we introduce a >>> >>> flag indicating whether a particular prefix should be protected or >>>not. >>> >>> A node-sid only dictates what (intermediate) node traffic should >>> >>> be sent to - not what >>> >>> link(s) are used to reach that node. >>> >> [Pushpasis] This is not about which links to take. It is about >>> >> wether transit routers should try to protect the node-segment to >>> >> the this node-sid or not. I think this opens up a lot many number >>> >> of possibilities on the ingress router and TE controller-based >>>applications. >>> >> >>> >>> >>> >>> Adjacency-sids have a different semantic - they identify the link >>> >>> over which traffic is to be forwarded. Identifying an >>> >>> adjacency-sid as unprotected means traffic will NEVER flow over a >>>different link. >>> >>> There is no equivalent behavior w a node-sid - which is what this >>> >>> discussion has been about. >>> >> [Pushpasis] I am not trying to draw a parallel between this new >>> >> flag and the ŒB¹ flag in Adj-Sid SubTlv. Like said before >>> >> >>> >>> >>> >>> Les >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Pushpasis Sarkar [mailto:psarkar@juniper.net] >>> >>> Sent: Sunday, January 04, 2015 8:51 AM >>> >>> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak >>> >>> (ppsenak); >>> >>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>> Subject: Re: [OSPF] [Isis-wg] Mail regarding >>> >>> draft-ietf-ospf-segment-routing-extensions >>> >>> >>> >>> Hi Les, >>> >>> >>> >>> I think the requirement Shraddha is referring is about the choice >>> >>> of exact node-sid to use while constructing the label-stack for a >>> >>> explicit-LSP on the ingress router, which will be typically done >>> >>> after running some CSPF on the SPRING topology. And not the IGP >>> >>> on ingress or transit routers. >>> >>> >>> >>> Thanks >>> >>> -Pushpasis >>> >>> >>> >>> On 1/3/15, 3:10 AM, "Les Ginsberg (ginsberg)" >>> >>> <ginsberg@cisco.com> >>> wrote: >>> >>> >>> >>>> Shraddha - >>> >>>> >>> >>>> IGPs today do NOT perform constraint based SPFs - so I don't >>> >>>> know why you believe that the primary SPF will meet a set of >>> >>>> constraints that an LFA calculation will not. In fact , it is >>> >>>> the opposite which is true because implementations today do >>> >>>> support preferences in choosing LFAs based on various configured >>> >>>> policy - something which is NOT done for primary SPF. >>> >>>> >>> >>>> If you want a certain class of traffic to avoid a subset of the >>> >>>> links in the topology then you need to have a way of identifying >>> >>>> the links (NOT the node addresses) and a way of calculating a >>> >>>> path which only uses the links which meet the constraints of >>> >>>> that class of >>> service. >>> >>>> Identifying a particular prefix as protected or unprotected >>> >>>> won't achieve that. >>> >>>> >>> >>>> Les >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Shraddha Hegde [mailto:shraddha@juniper.net] >>> >>>> Sent: Friday, January 02, 2015 10:54 AM >>> >>>> To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak); >>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>> Subject: RE: [Isis-wg] Mail regarding >>> >>>> draft-ietf-ospf-segment-routing-extensions >>> >>>> >>> >>>> Hi Les/Peter, >>> >>>> >>> >>>> When reconvergence happens, the primary path will be >>> >>>> calculated based on all constriants. >>> >>>> This is not true with the protection path.Protection path is >>> >>>> calculated locally (LFA/RLFA) and does not consider the >>> >>>> characteristics of the services running on that path. >>> >>>> It's easier for some services to pick the unprotected path when >>> >>>> the nature of the service is that it can be restarted when >>> >>>> there is a disconnection. >>> >>>> >>> >>>> Rgds >>> >>>> Shraddha >>> >>>> -----Original Message----- >>> >>>> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] >>> >>>> Sent: Friday, January 02, 2015 10:06 PM >>> >>>> To: Peter Psenak (ppsenak); Shraddha Hegde; >>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>> Subject: RE: [Isis-wg] Mail regarding >>> >>>> draft-ietf-ospf-segment-routing-extensions >>> >>>> >>> >>>> Peter - >>> >>>> >>> >>>> The requirement Shraddha specified was to not allow a particular >>> >>>> class of service ("heavy bandwidth services" was the example >>> >>>> provided) to use certain links in the topology. My point is that >>> >>>> advertising a flag for a given prefix which says "do not >>> >>>> calculate a repair path for this prefix" >>> >>>> does not help achieve this. Once the network reconverges >>> >>>> following the failure of one of the links on which "heavy >>>bandwidth services" >>> >>>> is allowed/preferred it is quite likely that the new best path >>> >>>> will be over a link on which "heavy bandwidth services" is NOT >>> >>>> allowed/preferred. This will happen whether you have the new >>> >>>> flag or not - so the flag will have no lasting effect. It would >>> >>>> only affect traffic flow during the brief period during which >>> >>>> the network is reconverging. >>> >>>> >>> >>>> I think you and I are actually in agreement - I am simply >>> >>>> sending a stronger negative message - not only do I think the >>> >>>> flag is not useful >>> >>>> - I think it does not achieve the goal Shraddha has in mind. >>> >>>> >>> >>>> Les >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Peter Psenak (ppsenak) >>> >>>> Sent: Friday, January 02, 2015 12:18 AM >>> >>>> To: Les Ginsberg (ginsberg); Shraddha Hegde; >>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>> Subject: Re: [Isis-wg] Mail regarding >>> >>>> draft-ietf-ospf-segment-routing-extensions >>> >>>> >>> >>>> Hi Les, >>> >>>> >>> >>>> I believe the idea is not to exclude any particular link, it's >>> >>>> actually much simpler - do not calculate backup for the prefix >>> >>>> if the flag is set. >>> >>>> >>> >>>> I'm still not quite sure how useful above is, but technically it >>> >>>> is possible. >>> >>>> >>> >>>> thanks, >>> >>>> Peter >>> >>>> >>> >>>> On 12/30/14 17:22 , Les Ginsberg (ginsberg) wrote: >>> >>>>> Shraddha - >>> >>>>> >>> >>>>> When performing a best path calculation whether a given link is >>> >>>>> in the set of best paths (to be protectedED) or not (could be >>> >>>>> used as a protectING path) is a function of the topology - not >>>the link. >>> >>>>> If there is a topology change it is quite likely that a given >>> >>>>> link will change from being a protectED link to being a >>> >>>>> protectING link (or vice versa). >>> >>>>> So what you propose regarding node-SIDs would not work. >>> >>>>> >>> >>>>> In the use case you mention below if you don't want a certain >>> >>>>> class of traffic to flow on a given link it requires a link >>> >>>>> attribute which is persistent across topology changes. There >>> >>>>> are ways to do that - using Adj-SIDs is one of them. But using >>> >>>>> node-SIDs in the way you propose is NOT. >>> >>>>> >>> >>>>> Les >>> >>>>> >>> >>>>> -----Original Message----- >>> >>>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Shraddha >>> >>>>> Hegde >>> >>>>> Sent: Monday, December 29, 2014 10:12 PM >>> >>>>> To: Peter Psenak (ppsenak); >>> >>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>>> Subject: Re: [OSPF] [Isis-wg] Mail regarding >>> >>>>> draft-ietf-ospf-segment-routing-extensions >>> >>>>> >>> >>>>> Peter, >>> >>>>> >>> >>>>>> The requirement here is to get an un-protected path for >>> >>>>>> services which do not want to divert the traffic on protected >>>path in any case. >>> >>>>> >>> >>>>>> can you give an example of such a service and a reasoning why >>> >>>>>> such service would want to avoid local protection along the >>>path? >>> >>>>> >>> >>>>> Heavy bandwidth services are potential candidates. The network >>> >>>>> is well planned and well provisioned for primary path but same >>> >>>>> is not true for backup paths. >>> >>>>> Diverting heavy bandwidth services along protection path can >>> >>>>> disrupt the other services on that path, they are better-off >>> >>>>> un-protected so that an event in the network Would result in >>> >>>>> disconnection and a retry for such services. >>> >>>>> >>> >>>>> Rgds >>> >>>>> Shraddha >>> >>>>> >>> >>>>> -----Original Message----- >>> >>>>> From: Peter Psenak [mailto:ppsenak@cisco.com] >>> >>>>> Sent: Monday, December 29, 2014 4:35 PM >>> >>>>> To: Shraddha Hegde; >>> >>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>>> Subject: Re: [Isis-wg] Mail regarding >>> >>>>> draft-ietf-ospf-segment-routing-extensions >>> >>>>> >>> >>>>> Shraddha, >>> >>>>> >>> >>>>> On 12/29/14 10:06 , Shraddha Hegde wrote: >>> >>>>>> Peter, >>> >>>>>> >>> >>>>>> The requirement here is to get an un-protected path for >>> >>>>>> services which do not want to divert the traffic on protected >>>path in any case. >>> >>>>> >>> >>>>> can you give an example of such a service and a reasoning why >>> >>>>> such service would want to avoid local protection along the path? >>> >>>>> >>> >>>>> thanks, >>> >>>>> Peter >>> >>>>> >>> >>>>>> So when the originator of node-sid signals un-protected path >>> >>>>>> requirement, there is always an unprotected path. >>> >>>>>> >>> >>>>>> Regarding the protected path, it is the default behavior as it >>> >>>>>> exists today. You get protection if it's available otherwise >>> >>>>>> you don't get protection. >>> >>>>>> >>> >>>>>> In fact, you can have the new flag to say "NP flag" meaning >>> >>>>>> non-protected flag which can be set for the unprotected path. >>> >>>>>> By default it remains off and gives the behavior as it exists >>>today. >>> >>>>>> >>> >>>>>> >>> >>>>>> Rgds >>> >>>>>> Shraddha >>> >>>>>> >>> >>>>>> -----Original Message----- >>> >>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com] >>> >>>>>> Sent: Monday, December 29, 2014 2:26 PM >>> >>>>>> To: Shraddha Hegde; >>> >>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>>>> Subject: Re: [Isis-wg] Mail regarding >>> >>>>>> draft-ietf-ospf-segment-routing-extensions >>> >>>>>> >>> >>>>>> Shraddha, >>> >>>>>> >>> >>>>>> I do not see how an originator of the node-sid can mandate a >>> >>>>>> protection for the prefix on other routers. What if there is >>> >>>>>> no backup available on a certain node along the path? >>> >>>>>> >>> >>>>>> The parallel with the B-flag in adj-sids is not right - in >>> >>>>>> case of adj-sid the originator has the knowledge about the >>> >>>>>> local adjacency protection and as such can signal it it it's >>>LSA. >>> >>>>>> >>> >>>>>> thanks, >>> >>>>>> Peter >>> >>>>>> >>> >>>>>> >>> >>>>>> On 12/29/14 09:47 , Shraddha Hegde wrote: >>> >>>>>>> Peter, >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> Pls see inline. >>> >>>>>>> >>> >>>>>>> Rgds >>> >>>>>>> Shraddha >>> >>>>>>> >>> >>>>>>> -----Original Message----- >>> >>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com] >>> >>>>>>> Sent: Monday, December 29, 2014 2:02 PM >>> >>>>>>> To: Shraddha Hegde; >>> >>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>>>>> Subject: Re: [Isis-wg] Mail regarding >>> >>>>>>> draft-ietf-ospf-segment-routing-extensions >>> >>>>>>> >>> >>>>>>> Shraddha, >>> >>>>>>> >>> >>>>>>> I do not see how an originator can set any flag regarding the >>> >>>>>>> protection of the locally attached prefix. >>> >>>>>>> <Shraddha> The originator advertises 2 node-sids. One with p >>> >>>>>>> flag set and the other without the p-flag set. >>> >>>>>>> >>> >>>>>>> It's all the routers on the path towards such prefix that >>> >>>>>>> need to deal with the protection. >>> >>>>>>> <Shraddha> The receiving nodes will download protected path >>> >>>>>>> for the node-sid with p-flag set and download Unprotected >>> >>>>>>> path for the node-sid with p-flag unset. >>> >>>>>>> >>> >>>>>>> Signaling anything from the originator seems useless. >>> >>>>>>> <Shraddha> For node-sids it's the others who need to build >>> >>>>>>> the forwarding plane but it's only the originator who can >>>signal which of >>> >>>>>>> Sid need to be built with >>> >>>>>>> protection and which not. Other routers on the path cannot >>> >>>>>>> signal this information. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>>> >>> >>>>>>> With this you have two paths for the node. One is protected >>> >>>>>>> and the other is unprotected. This meets the requirement of >>> >>>>>>> having an un-protected path. >>> >>>>>>> >>> >>>>>>> It's very much in parallel to B-flag in adj-sids. It is >>> >>>>>>> similar to advertising multiple adj-sids one with B-flag on >>> >>>>>>> and other with b-flag off , to get protected and unprotected >>>Adj-sids. >>> >>>>>>> >>> >>>>>>> thanks, >>> >>>>>>> Peter >>> >>>>>>> >>> >>>>>>> On 12/29/14 09:26 , Shraddha Hegde wrote: >>> >>>>>>>> Yes.You are right. >>> >>>>>>>> >>> >>>>>>>> Lets say a prefix sid has a flag "p flag". If this is on it >>> >>>>>>>> means build a path and provide protection. >>> >>>>>>>> If this is off it means build a path with no protection. >>> >>>>>>>> The receivers of the prefix-sid will build forwarding plane >>> >>>>>>>> based on this flag. >>> >>>>>>>> >>> >>>>>>>> The applications building the paths will either use >>> >>>>>>>> prefix-sids with p flag on or off based on the need of the >>>service. >>> >>>>>>>> Rgds >>> >>>>>>>> Shraddha >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> -----Original Message----- >>> >>>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com] >>> >>>>>>>> Sent: Monday, December 29, 2014 1:49 PM >>> >>>>>>>> To: Shraddha Hegde; >>> >>>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>>>>>> Subject: Re: [Isis-wg] Mail regarding >>> >>>>>>>> draft-ietf-ospf-segment-routing-extensions >>> >>>>>>>> >>> >>>>>>>> Shraddha, >>> >>>>>>>> >>> >>>>>>>> the problem is that the node that is advertising the >>> >>>>>>>> node-sid can not advertise any data regarding the protection >>> >>>>>>>> of such prefix, because the prefix is locally attached. >>> >>>>>>>> >>> >>>>>>>> thanks, >>> >>>>>>>> Peter >>> >>>>>>>> >>> >>>>>>>> On 12/29/14 09:15 , Shraddha Hegde wrote: >>> >>>>>>>>> Peter, >>> >>>>>>>>> >>> >>>>>>>>> If there is a service which has to use un-protected path >>> >>>>>>>>> and while building such a path if the node-sids Need to be >>> >>>>>>>>> used (one reason could be label stack compression) , then >>> >>>>>>>>> there has to be unprotected node-sid that this service can >>> >>>>>>>>> make use >>> of. >>> >>>>>>>>> >>> >>>>>>>>> Prefix -sids could also be used to represent different >>> >>>>>>>>> service endpoints which makes it even more relevant to have >>> >>>>>>>>> A means >>> of >>> >>>>>>>>> representing unprotected paths. >>> >>>>>>>>> >>> >>>>>>>>> Would be good to hear from others on this, especially >>>operators. >>> >>>>>>>>> >>> >>>>>>>>> Rgds >>> >>>>>>>>> Shraddha >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> -----Original Message----- >>> >>>>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com] >>> >>>>>>>>> Sent: Monday, December 29, 2014 1:35 PM >>> >>>>>>>>> To: Shraddha Hegde; >>> >>>>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; >>> >>>>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org >>> >>>>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org >>> >>>>>>>>> Subject: Re: [Isis-wg] Mail regarding >>> >>>>>>>>> draft-ietf-ospf-segment-routing-extensions >>> >>>>>>>>> >>> >>>>>>>>> Shraddha, >>> >>>>>>>>> >>> >>>>>>>>> node-SID is advertised by the router for the prefix that is >>> >>>>>>>>> directly attached to it. Protection for such local prefix >>> >>>>>>>>> does not mean much. >>> >>>>>>>>> >>> >>>>>>>>> thanks, >>> >>>>>>>>> Peter >>> >>>>>>>>> >>> >>>>>>>>> On 12/24/14 11:57 , Shraddha Hegde wrote: >>> >>>>>>>>>> Authors, >>> >>>>>>>>>> We have a "backup flag" in adjacency sid to indicate >>> >>>>>>>>>> whether the label is protected or not. >>> >>>>>>>>>> Similarly. I think we need a flag in prefix-sid as well to >>> >>>>>>>>>> indicate whether the node-sid is to be protected or not. >>> >>>>>>>>>> Any thoughts on this? >>> >>>>>>>>>> Rgds >>> >>>>>>>>>> Shraddha >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> Isis-wg mailing list >>> >>>>>>>>>> Isis-wg@ietf.org >>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> . >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>>> . >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> . >>> >>>>>>> >>> >>>>>> >>> >>>>>> . >>> >>>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> OSPF mailing list >>> >>>>> OSPF@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>>>> . >>> >>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> OSPF mailing list >>> >>>> OSPF@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> >>> >> >>> > >>> > _______________________________________________ >>> > Isis-wg mailing list >>> > Isis-wg@ietf.org >>> > 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. >>> > >>> > _______________________________________________ >>> > Isis-wg mailing list >>> > Isis-wg@ietf.org >>> > 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. >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >>_______________________________________________________________________ >>___ _______________________________________________ >> >>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 >>OSPF@ietf.org >>https://www.ietf.org/mailman/listinfo/ospf > > >__________________________________________________________________________ >_______________________________________________ > >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] Mail regarding draft-ietf-ospf-segment-rou… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Peter Psenak
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Peter Psenak
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Peter Psenak
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Peter Psenak
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Rob Shakir
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Rob Shakir
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Rob Shakir
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Peter Psenak
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Peter Psenak
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Peter Psenak
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Pushpasis Sarkar
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Jeff Tantsura
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Pushpasis Sarkar
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Pushpasis Sarkar
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Pushpasis Sarkar
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Mitchell Erblich
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Shraddha Hegde
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Les Ginsberg (ginsberg)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Rob Shakir
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… stephane.litkowski
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… stephane.litkowski
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… stephane.litkowski
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… bruno.decraene
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… stephane.litkowski
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… bruno.decraene
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Henderickx, Wim (Wim)
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… stephane.litkowski
- Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-os… Henderickx, Wim (Wim)