Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Mitchell Erblich <erblichs@earthlink.net> Mon, 05 January 2015 07:06 UTC

Return-Path: <erblichs@earthlink.net>
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 A0A201A1BE6; Sun, 4 Jan 2015 23:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 YiQxfiZrBYIh; Sun, 4 Jan 2015 23:06:06 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7B61A1BDF; Sun, 4 Jan 2015 23:06:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JNrnGWVrFzf2QVrHLnspfyXJJn2Wiw7GehkYGa409OsMvsxI5ylYzR42VkIlmv/4; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [76.21.83.101] (helo=[10.0.1.4]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <erblichs@earthlink.net>) id 1Y81je-0005ak-7P; Mon, 05 Jan 2015 02:05:54 -0500
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mitchell Erblich <erblichs@earthlink.net>
In-Reply-To: <F3ADE4747C9E124B89F0ED2180CC814F4EEA29A2@xmb-aln-x02.cisco.com>
Date: Sun, 04 Jan 2015 23:05:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7EFCAF5-C7A9-4C9E-84B5-EA546D2FD67B@earthlink.net>
References: <D0CF6C5B.1B6DD%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA26EF@xmb-aln-x02.cisco.com> <D0D00E58.1B720%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA29A2@xmb-aln-x02.cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79642da24539358884cd678c9ac4f5ed8d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.21.83.101
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/uQ8j7enQoJN9WdsyFzZdLZdoQx4
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-segment-routing-extensions@tools.ietf.org>, "ospf@ietf.org" <ospf@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, 05 Jan 2015 07:06:12 -0000

Les Ginsberg et al, , ,

	First, I only really monitor this alias, as I am a Kernel Engineer, 
	Thus, if I am a mile off track then please don’t stone me…

Summary:
	Isn’t this a local routing decision that needs to be made by router B..??? Or C in the reverse path? Then why do we need protection from B if the B-C link goes down?
	Can’t B just make a local routing decision especially if B is a DR (assuming OSPF), without notifying anyone… other than use me to get to routers “C” & “D”. Yes, assuming that no DR-others or systems reside off the routers E & F?  Yes, simple case…
	Then do you MUST know which path/link B is using?

	…
Detail:
	But, assuming that that B-C path has a high cost, or is a slow link, or overloaded, or over-subscribed, or equiv versus taking the path B-E-F-D, or taking NONE

	Then why not allow:

			Normally…
			* two paths exist and load can be balanced or  just one path preferred over the other path..
`			* a router can explicity specify the B-E-F-C path , say simply … pinging the path/links one hop at a time,, then why invalidate it just because of convergence?
		
			Allowing that both path’s to simultaneously exist,  aren’t you then 0’ering out the convergence time to switch and identify one path as primary..
				the assumption is that B makes the routing decision and doesn’t really have to advertise if a local route goes down… (say advertise its path to D as a worse case..)
																						Why worse case? don’t want the rexmit algors to kick in early..
			And we follow this logic then ,,, if one is primary whether the link of B-C or B-E-F-C or NONE COULD be a local routing decision made by B…
			No, I do not assume that the reverse path is identical to the forward path…

		So, the question to myself is whether and how B either transparently advertises its path to D, or whether it explicitly/implicity advertises one or BOTH paths.. on a multually exclusive…

		If a convergence is the deciding factor, and both alternative paths/routes flap, then aren’t you effectively preventing the route to router “D”  or think that you can reach D because of recv’ing pkts from D..
		Normally don’t advertise a route unless it is a stable route … Right?

		So, I would think a method is needed to allow router B, how/if it wishes to advertise its localized routes, but not force B to switch advertising and routing back a forth…


		Mitchell Erblich

	
			
On Jan 4, 2015, at 9:53 PM, 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).
> 
> 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.
> 
> 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
>> 
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf