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

Shraddha Hegde <shraddha@juniper.net> Mon, 29 December 2014 09:06 UTC

Return-Path: <shraddha@juniper.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 8DB6F1A005E; Mon, 29 Dec 2014 01:06:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 lo7M9jEJoQDF; Mon, 29 Dec 2014 01:06:09 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D98B1A005D; Mon, 29 Dec 2014 01:06:08 -0800 (PST)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 09:06:06 +0000
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([25.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([25.160.107.139]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 09:06:06 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Peter Psenak <ppsenak@cisco.com>, "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-segment-routing-extensions@tools.ietf.org>, "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" <draft-ietf-isis-segment-routing-extensions@tools.ietf.org>
Thread-Topic: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
Thread-Index: AdAfZ+2t8gRxJR1gRJOVEF41ljB4rwD1jwiAAAAaeDAAAGH0AAAABIpwAABwSQAAABH9IAAAx7iAAAAQr4A=
Date: Mon, 29 Dec 2014 09:06:06 +0000
Message-ID: <BY1PR0501MB138100AA25B6773A7EAB5A49D5510@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <BY1PR0501MB13819883015276791F20D631D5540@BY1PR0501MB1381.namprd05.prod.outlook.com> <54A10B35.4030301@cisco.com> <BY1PR0501MB1381B131A68B321264B7E930D5510@BY1PR0501MB1381.namprd05.prod.outlook.com> <54A10E78.6030006@cisco.com> <BY1PR0501MB1381610E47F46E81528B5416D5510@BY1PR0501MB1381.namprd05.prod.outlook.com> <54A11188.8040301@cisco.com> <BY1PR0501MB1381860D81EE3DF32A76B6D7D5510@BY1PR0501MB1381.namprd05.prod.outlook.com> <54A1173D.6000200@cisco.com>
In-Reply-To: <54A1173D.6000200@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.10]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net;
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1381;
x-forefront-prvs: 0440AC9990
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(377454003)(24454002)(199003)(479174004)(13464003)(62966003)(92566001)(97736003)(54356999)(54206007)(4396001)(74316001)(19580395003)(76576001)(19580405001)(46102003)(77156002)(120916001)(106356001)(99396003)(86362001)(93886004)(68736005)(50986999)(102836002)(76176999)(87936001)(2656002)(2201001)(99286002)(64706001)(230783001)(66066001)(101416001)(31966008)(33656002)(54606007)(107046002)(15975445007)(40100003)(21056001)(2950100001)(122556002)(2900100001)(20776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1381; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 09:06:06.4195 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1381
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/3I2xz-VUnvgHu9i37nrm0IA-YAQ
Cc: "ospf@ietf.org" <ospf@ietf.org>, "isis-wg@ietf.org" <isis-wg@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, 29 Dec 2014 09:06:13 -0000

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.
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
>>>>
>>>
>>> .
>>>
>>
>> .
>>
>
> .
>