Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

Shraddha Hegde <shraddha@juniper.net> Tue, 16 December 2014 17:31 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 051281A1B9B for <ospf@ietfa.amsl.com>; Tue, 16 Dec 2014 09:31:35 -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 zNQQTl6puf4b for <ospf@ietfa.amsl.com>; Tue, 16 Dec 2014 09:31:32 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EE81A1B49 for <ospf@ietf.org>; Tue, 16 Dec 2014 09:31:31 -0800 (PST)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1383.namprd05.prod.outlook.com (25.160.107.141) with Microsoft SMTP Server (TLS) id 15.1.36.23; Tue, 16 Dec 2014 17:31:30 +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.0031.000; Tue, 16 Dec 2014 17:31:29 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "rob.shakir@bt.com" <rob.shakir@bt.com>, "ppsenak@cisco.com" <ppsenak@cisco.com>, "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-segment-routing-extensions@tools.ietf.org>
Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03
Thread-Index: AdAW/kuWGscufT8EQDeA0Yv5U29aiwAi7qSAAGZ5RmAACscGgAABGydw
Date: Tue, 16 Dec 2014 17:31:29 +0000
Message-ID: <BY1PR0501MB13811178FB2F413C670A0B45D56C0@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <BY1PR0501MB13814F720E08CE2F7F36BE44D56C0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D0B60FCD.70368%rob.shakir@bt.com>
In-Reply-To: <D0B60FCD.70368%rob.shakir@bt.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.19]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1383;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1383;
x-forefront-prvs: 04270EF89C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(13464003)(377454003)(51704005)(189002)(479174004)(164054003)(99286002)(105586002)(106356001)(68736005)(230783001)(107046002)(19580405001)(19580395003)(101416001)(4396001)(2950100001)(2900100001)(102836002)(74316001)(99396003)(86362001)(2201001)(92566001)(50986999)(2501002)(62966003)(77156002)(54356999)(97736003)(76176999)(40100003)(120916001)(122556002)(87936001)(76576001)(2656002)(20776003)(64706001)(31966008)(46102003)(66066001)(33656002)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1383; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
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: 16 Dec 2014 17:31:29.4682 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1383
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/SL5cD13B3yQ9nEdZ511xsl9ZI9w
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03
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: Tue, 16 Dec 2014 17:31:35 -0000

Rob,

Pls see inline..

-----Original Message-----
From: rob.shakir@bt.com [mailto:rob.shakir@bt.com] 
Sent: Tuesday, December 16, 2014 10:11 PM
To: Shraddha Hegde; ppsenak@cisco.com; draft-ietf-ospf-segment-routing-extensions@tools.ietf.org
Cc: ospf@ietf.org
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

Is it really up to the neighbor to specify what was previously a bundle?

<Shraddha>  The graceful restart in OSPF as per RFC  3623 works by learning  the LSAs from neighbor after the restating router comes up and builds the LSA database based on the learnt 		LSAs.
	          The neighbor relays back the LSA generated by the restarting router. The Extended link LSA contains the adj-sid Label TLV which
                           Has the "s bit" set indicating the label is a set label. If there are multiple such set labels associated with a link, its difficult to associate which label was allocated for which bundle.
                    
                          If there is a some kind of identifier for the bundle, the label can be easily associated.


It is surely the local configuration of the node that determines what the bundle is in the first place, and this is persistent over a graceful-restart of the session?

<Shraddha> Yes, IMO local configuration decides which links belong to the bundle. This configuration is persistent over graceful restart.
                          You MAY want to bundle all the parallel links between two nodes into a bundle, in which case the existing protocol operations work fine.
                           But I think protocol should provide flexibility to make multiple bundles, able to assign a link to multiple bundles (if so desired) and recovering the label across restart.                


Thanks,
r.

[16/12/2014 16:34, "Shraddha Hegde" <shraddha@juniper.net>]

>Peter,
>
>An extended link LSA can contain multiple adj-sid labels with "s bit" set.
>During graceful restart , when self generated LSAs are learnt from 
>neighbors, A handle is required to associate the set label with the 
>bundle.
>
>I think a group-id field along with set label would serve the purpose.
>
>Rgds
>Shraddha
>-----Original Message-----
>From: Peter Psenak [mailto:ppsenak@cisco.com]
>Sent: Sunday, December 14, 2014 4:08 PM
>To: Shraddha Hegde;
>draft-ietf-ospf-segment-routing-extensions@tools.ietf.org
>Cc: OSPF WG List
>Subject: Re: draft-ietf-ospf-segment-routing-extensions-03
>
>Shraddha,
>
>the idea is that you can assign the same Adj-SID to multiple links. 
>That way you can create multiple sets as you need.
>
>thanks,
>Peter
>
>
>On 12/13/14 19:19 , Shraddha Hegde wrote:
>> Authors,
>>
>>          When there are multiple parallel links between two nodes, it 
>> is useful to
>>
>> Group them into different bundles and use each bundle for load-balancing
>>   for different traffic flows.
>>
>> What we have in adjacency sid is just a flag to indicate that the 
>> label is a "set label" by setting a flag
>>
>> In adj-sid TLV. It serves the purpose when all the parallel links  
>> are in one bundle but not sufficient when
>>
>> There can be different bundles and different labels for each of them.
>>
>> An identifier for the group, probably "group-id" is needed to 
>> associate the label with the interface group.
>>
>> Any thoughts on this?
>>
>> Rgds
>>
>> Shraddha
>>
>