Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> Mon, 12 January 2015 10:44 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 4E67D1A8ABD; Mon, 12 Jan 2015 02:44:47 -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 Pw4xrKsFEFJg; Mon, 12 Jan 2015 02:44:39 -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 1241B1A0191; Mon, 12 Jan 2015 02:44:39 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id F181283159E1B; Mon, 12 Jan 2015 10:44:34 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t0CAiWZk011767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 11:44:32 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 11:44:31 +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+CAgAARysCAAB57gA==
Date: Mon, 12 Jan 2015 10:44:31 +0000
Message-ID: <D0D9633B.11A80B%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>
In-Reply-To: <21149_1421052896_54B38BE0_21149_1085_1_86923dca-49c3-4745-881c-116ec27cb9f2@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.40]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9C99534823F1234E836E76B0624E198B@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/ggbo5MFJQZcVeuox7aqjMvcw9fg>
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 10:44:47 -0000
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
- [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)