From nobody Mon Dec 1 15:06:38 2014 Return-Path: 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 5CBBB1ACD2B for ; Mon, 1 Dec 2014 15:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 AEC4KN271xIN for ; Mon, 1 Dec 2014 15:06:31 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DED1AC422 for ; Mon, 1 Dec 2014 15:06:31 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 79so5301343ykr.28 for ; Mon, 01 Dec 2014 15:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7FgEszG8jkkpACyFH6k1d/VZGn3iLDZ81uvJPY0XBZk=; b=zYpyQYn9hCZrA6Xl+yjbck3Zij7hXvIIriPWvyvubMOs1gYZrMwvTEx01cPHl8OtTI NECg/SkDI5WvvNDa0/NjuJVgZXJ8Ey7Fk3S+sq4jrj8ddWJNyuQe4nwFUhFsincB/4ya PeGFD3Q4jCu0/jIs+XpP0s7n5cY7Y0pivS7fuBo17DpwKHBYAko3Sx3pc/uYsQIs9GHf TWhliXdvLqlN8GOANAoc5lm+SRdE96cjikIIElCYOQgjxcJ4CGr2S2PhmjT7RIxxuOYT zWlS1eWXdEgx0VcekfEjWIPnXgAi1VDVdIL/zU0fDYDGFTEzFR3vqLRXAqcmWwq53gBv U2PQ== MIME-Version: 1.0 X-Received: by 10.170.122.134 with SMTP id o128mr60908540ykb.55.1417475190256; Mon, 01 Dec 2014 15:06:30 -0800 (PST) Received: by 10.170.172.86 with HTTP; Mon, 1 Dec 2014 15:06:30 -0800 (PST) In-Reply-To: <300adc6a58d24dd0873bf13964107168@BLUPR05MB562.namprd05.prod.outlook.com> References: <300adc6a58d24dd0873bf13964107168@BLUPR05MB562.namprd05.prod.outlook.com> Date: Mon, 1 Dec 2014 18:06:30 -0500 Message-ID: From: Alia Atlas To: John E Drake Content-Type: multipart/alternative; boundary=001a1139da8031794105092fa941 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/1ZNdAJPzqvWNW4gf3qoCdE_nZPo Cc: OSPF WG List , Alia Atlas , "David Ward \(wardd\)" Subject: Re: [OSPF] IPR on OSPF TE Metric Extensions X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 23:06:34 -0000 --001a1139da8031794105092fa941 Content-Type: text/plain; charset=UTF-8 I am also not aware of any IPR. On Mon, Nov 17, 2014 at 11:34 AM, John E Drake wrote: > I'm not aware of any. > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: Acee Lindem (acee) [mailto:acee@cisco.com] > > Sent: Sunday, November 16, 2014 8:54 PM > > To: John E Drake; Spencer Giacalone; David Ward (wardd); Alia Atlas; > Stefano > > Previdi (sprevidi) > > Cc: OSPF WG List > > Subject: IPR on OSPF TE Metric Extensions > > > > Authors please confirm whether or not you know of any IPR other than the > > two disclosures listed below. > > > > https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft > > -ie > > tf-ospf-te-metric-extensions > > > > Thanks, > > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --001a1139da8031794105092fa941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am also not aware of any IPR.

On Mon, Nov 17, 2014 at 11:34 AM, John= E Drake <jdrake@juniper.net> wrote:
I'm not aware of any.

Yours Irrespectively,

John

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:ace= e@cisco.com]
> Sent: Sunday, November 16, 2014 8:54 PM
> To: John E Drake; Spencer Giacalone; David Ward (wardd); Alia Atlas; S= tefano
> Previdi (sprevidi)
> Cc: OSPF WG List
> Subject: IPR on OSPF TE Metric Extensions
>
> Authors please confirm whether or not you know of any IPR other than t= he
> two disclosures listed below.
>
> https://datatracker.ietf.org/ipr/s= earch/?option=3Ddocument_search&id=3Ddraft
> -ie
> tf-ospf-te-metric-extensions
>
> Thanks,
> Acee

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--001a1139da8031794105092fa941-- From nobody Tue Dec 2 08:51:09 2014 Return-Path: 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 03E031A1EEE for ; Tue, 2 Dec 2014 08:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 K6tu4nHdxeST for ; Tue, 2 Dec 2014 08:51:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::734]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037F51A1EF5 for ; Tue, 2 Dec 2014 08:50:35 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1448.namprd05.prod.outlook.com (25.160.108.12) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 16:50:13 +0000 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.26.15; Tue, 2 Dec 2014 16:50:11 +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.0026.003; Tue, 2 Dec 2014 16:50:11 +0000 From: Shraddha Hegde To: "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAOT6Fi+HUt3MSBSRa5ydDMnUARfw== Date: Tue, 2 Dec 2014 16:50:11 +0000 Message-ID: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1381;UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1381; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(31966008)(4396001)(229853001)(54356999)(110136001)(66066001)(21056001)(50986999)(74316001)(64706001)(230783001)(20776003)(77156002)(108616004)(76576001)(62966003)(120916001)(105586002)(87936001)(40100003)(122556002)(33646002)(99396003)(86362001)(92566001)(2351001)(107046002)(101416001)(46102003)(106356001)(15975445006)(2656002)(15202345003)(77096004)(99286002)(68736005)(95666004)(19580395003)(97736003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1381; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net; Content-Type: multipart/alternative; boundary="_000_64c8be7dc5744779b0a119ac0584777cBY1PR0501MB1381namprd05_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1448; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ofsEJokOEIg-cc87g24ug6pxGdc Cc: OSPF WG List Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 16:51:07 -0000 --_000_64c8be7dc5744779b0a119ac0584777cBY1PR0501MB1381namprd05_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Some comments on the draft. 1. The draft refers to the various use cases in the use case document = in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the section o= f the use case draft which is applicable for each reference instead of givi= ng generic reference. 2. Section 7.2 LAN Adj-sid sub TLV: Based on the description of the text it appears that the LAN AdjSID Sub= TLV can contain multiple neighbor-ID /SID pairs based on the nodes attache= d to a broadcast network. The TLV diagram should depict carrying multiple s= uch pairs. "It is used to advertise a SID/Label for an adjacency to a non-DR node on a broadcast or NBMA network." Does the above statement mean only DR originates the LAN-Adj SID and adv= ertises label to non-DR nodes? Shouldn't each node in broadcast link originate LAN adj-SID and adve= rtise label to all other nodes on the link? 3. Adj-Sid sub TLV section 7.1: Description of V-flag mentions Prefix-SID, it should be changed to Adj= -SID. 4. Section 4: Extended prefix range TLV is very similar to Extended pr= efix TLV just that it has additional range associated with it. I would think that we should have "route type" as in Extended prefix TL= V instead of just having a bit indicating "inter area" Rgds Shraddha --_000_64c8be7dc5744779b0a119ac0584777cBY1PR0501MB1381namprd05_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors,
 
Some  comments on the draft.
 
  1. The draft refers to the various use cases in the use case document in I= -D.filsfils-rtgwg-segment-routing. It’s useful to mention the section= of the use case draft which is applicable for each reference instead of gi= ving generic reference.
  2. Section 7.2 LAN Adj-sid sub TLV:
Based on the description of the text it a= ppears that the LAN AdjSID Sub TLV can contain multiple neighbor-ID /SID pa= irs based on the nodes attached to a broadcast network. The TLV diagram sho= uld depict carrying multiple such pairs.
 
       “It is used to advertise a SID/L= abel for an
=    adjacency to a non-DR node on a broadcast or NBMA network.R= 21;
=  
=    Does the above statement mean only DR originates the LAN-Adj SID and advertises label to non-DR nodes?
      Shouldn’t each node in broadcast = link originate LAN adj-SID and advertise label to all other nodes on the l= ink?
 
  1. Adj-Sid sub TLV section 7.1:
Description of V-flag mentions Prefix-SID= ,  it should be changed to Adj-SID.
  1. Section 4: Extended prefix range TLV is very similar to Extended prefix= TLV just that it has additional range associated with it.
I would think that we should have "r= oute type" as in Extended prefix TLV instead of just having a bit indi= cating "inter area"
 
 
Rgds
Shraddha
 
 
 
 --_000_64c8be7dc5744779b0a119ac0584777cBY1PR0501MB1381namprd05_-- From nobody Tue Dec 2 09:09:00 2014 Return-Path: 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 2DED01A6EF1 for ; Tue, 2 Dec 2014 09:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 1K5KXE_wiR6C for ; Tue, 2 Dec 2014 09:08:44 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3BE1A6EF4 for ; Tue, 2 Dec 2014 09:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2108; q=dns/txt; s=iport; t=1417540124; x=1418749724; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pznj/m+qbDTm65DcUUwOw0uROdNMTxiPgqXAlvvmVBA=; b=aqCdS2LoRMTrZCCtLOuvcel8Rv5iNsTrppUToPdbJ4AseSuCUBeUG/Ga kKqGHuaGVR3QVQG6Xwct8GyPSZxmHT7aE3PbnsJpoQtDzQlD+ZVq5wtMM jI3pjILMAD4Fo3Pp4JSW/Fir6CsJWD8uxtbz93rLXsCY5on2/lkcEY0rw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FANDwfVStJV2T/2dsb2JhbABbgwfOWgKBIhYBAQEBAX2EAgEBAQMBMgEFQAEFCwsYCRYPCQMCAQIBRQYBDAEHAQGIMwnWSwEBAQEBAQEBAQEBAQEBAQEBAQEBGJBvB4RIAQScBoEsgziCYo1bg3w+gncBAQE X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="101958659" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 02 Dec 2014 17:08:43 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sB2H8g9b022370; Tue, 2 Dec 2014 17:08:42 GMT Message-ID: <547DF219.4020500@cisco.com> Date: Tue, 02 Dec 2014 18:08:41 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> In-Reply-To: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/3S2ZTlma092qyBwgiUc5zqOAYY8 Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:08:47 -0000 Shraddha, please see inline: On 12/2/14 17:50 , Shraddha Hegde wrote: > Authors, > Some comments on the draft. > > 1. The draft refers to the various use cases in the use case document > in I-D.filsfils-rtgwg-segment-routing. It’s useful to mention the > section of the use case draft which is applicable for each reference > instead of giving generic reference. sure, we can add that. > 2. Section 7.2 LAN Adj-sid sub TLV: > > Based on the description of the text it appears that the LAN AdjSID Sub > TLV can contain multiple neighbor-ID /SID pairs based on the nodes > attached to a broadcast network. The TLV diagram should depict carrying > multiple such pairs. no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor. If you have more non-DR neighbors, you need to advertise multiple LAN Adj-SID Sub-TLVs. > “It is used to advertise a SID/Label for an > adjacency to a non-DR node on a broadcast or NBMA network.” > Does the above statement mean only DR originates the LAN-Adj SIDand > advertises label to non-DR nodes? no. > Shouldn’t each node in broadcast link originate LAN adj-SID and > advertise label to all other nodes on the link? For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. > > 3. Adj-Sid sub TLV section 7.1: > > Description of V-flag mentions Prefix-SID, it should be changed to Adj-SID. good catch, will correct. > > 4. Section 4: Extended prefix range TLV is very similar to Extended > prefix TLV just that it has additional range associated with it. yes, that is correct. > > I would think that we should have "route type" as in Extended prefix TLV > instead of just having a bit indicating "inter area" route-type would be misleading for range, as single range can include prefixes of various types (intra, inter, external). We have discussed this between authors and we agreed route-type is not the right way. thanks, Peter > Rgds > Shraddha From nobody Tue Dec 2 16:52:03 2014 Return-Path: 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 7C29F1A8875 for ; Tue, 2 Dec 2014 16:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 VuoLEMbc0JLP for ; Tue, 2 Dec 2014 16:52:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3C51A1BC0 for ; Tue, 2 Dec 2014 16:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=344; q=dns/txt; s=iport; t=1417567920; x=1418777520; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5/pgUngxuMGAz4+pUO2r29kPIlz4GRV6S8rTjX4ghPM=; b=UqINB5oZSLS90yMMeRwJqPKvOkw/RvoRlRnSI/bo5K6DIF0d/39CSMVR KTj0fDuzO3pQYAAkIHvJsX4E3ikehk4U+vzXsGQ41LUXKMk71LQNMCsl7 RGmqfS7EYOMuVY2w+YAXXr0c0DEIo5024fLgNQccbFWY1EHRp7NXUofUE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAxeflStJV2U/2dsb2JhbABbgwdSWQTHE4c7FgEBAQEBfYQJgQsBgQAnBByINw2veKZOlT4FikqGF4slgSyDOIw7hAKBSYIybwGBRYEBAQEB X-IronPort-AV: E=Sophos;i="5.07,504,1413244800"; d="scan'208";a="373938782" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 03 Dec 2014 00:51:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB30pxh9016421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Dec 2014 00:51:59 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 18:51:59 -0600 From: "Acee Lindem (acee)" To: OSPF WG List Thread-Topic: OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" Thread-Index: AQHQDpNXZI6jJnSBTkWiIGV9XoGXjg== Date: Wed, 3 Dec 2014 00:51:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/XWLFg4Zb4RhRiWfAHtTy3yOCBLE Subject: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 00:52:01 -0000 We=B9ve been working on this for several IETFs now and the chairs believe i= t is time for WG adoption. Note that this document started in the NETMOD WG. Please indicate your support of opposition of WG adoptions. Here is a URL for your convenience: http://www.ietf.org/id/draft-yeung-netmod-ospf-02.txt Thanks, Acee and Abhay =20 From nobody Tue Dec 2 16:57:23 2014 Return-Path: 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 F057A1A887A for ; Tue, 2 Dec 2014 16:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 cXOmgQFH1boT for ; Tue, 2 Dec 2014 16:57:19 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9947C1A8850 for ; Tue, 2 Dec 2014 16:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=339; q=dns/txt; s=iport; t=1417568239; x=1418777839; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Yb6sjBAIwHaEoU8pH3FIoEp8zKvOcIJOcmB9nNZ0ir8=; b=Sn7sPU5DofCRVAM9WW6JqRUHNam8bhILRuyxlOK3XRDkEAD5ZnZ9CsQk vpjudAWDnpSsRFgfqRfaJJieLSO2bzLwvWfpPDyZlSDb5A9IqKPX2BA19 gPi1xf1B8IWt41IZj34cDVxkYJXPM2jrFoWz1krLuIQV1P4q6aH/x8Sf9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAKlfflStJA2J/2dsb2JhbABbgwdSWQTHE4c7FgEBAQEBfYQJgQsBgQAnBByINw2ve6ZLlT4FikqGF4slgSyDOIw7hAKBSW6BRG8BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,504,1413244800"; d="scan'208";a="377391216" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP; 03 Dec 2014 00:57:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB30vFp4014590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Dec 2014 00:57:15 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 18:57:15 -0600 From: "Acee Lindem (acee)" To: OSPF WG List Thread-Topic: OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) Thread-Index: AQHQDpQUQKQv9qcPok6eEYXmUp8Syw== Date: Wed, 3 Dec 2014 00:57:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6AC67A19FC03894D8F0555BED2502DB3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/xYHvIWf_PQienlgT17_LRfG2p78 Subject: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 00:57:21 -0000 We=B9ve been working on this for several IETFs now and the chairs believe i= t is time for WG adoption. Note that this document started in the NETMOD WG. Please indicate your support of opposition of WG adoptions. Here is a URL for your convenience: http://www.ietf.org/id/draft-yeung-netmod-ospf-02.txt Thanks, Acee and Abhay From nobody Tue Dec 2 21:11:05 2014 Return-Path: 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 5F8AF1A008B for ; Tue, 2 Dec 2014 21:11:03 -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 HI6oZjWYcdlv for ; Tue, 2 Dec 2014 21:11:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDDE1A0086 for ; Tue, 2 Dec 2014 21:11:00 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1382.namprd05.prod.outlook.com (25.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 3 Dec 2014 05:10:59 +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.0026.003; Wed, 3 Dec 2014 05:10:59 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAOT6Fi+HUt3MSBSRa5ydDMnUARfwAAv2KAABjvTgA= Date: Wed, 3 Dec 2014 05:10:58 +0000 Message-ID: References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> <547DF219.4020500@cisco.com> In-Reply-To: <547DF219.4020500@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1382; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(199003)(377454003)(189002)(479174003)(51704005)(74316001)(107046002)(2656002)(62966003)(87936001)(77156002)(120916001)(99396003)(122556002)(40100003)(97736003)(68736005)(101416001)(46102003)(230783001)(33656002)(76576001)(64706001)(92726001)(19580395003)(19580405001)(66066001)(31966008)(105586002)(86362001)(21056001)(99286002)(106356001)(20776003)(95666004)(50986999)(92566001)(54606007)(76176999)(54356999)(4396001)(54206007); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1382; 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 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/RxDq6oQBqf1kvRMehyU47vfERJ0 Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 05:11:03 -0000 Peter, > Shouldn't each node in broadcast link originate LAN adj-SID and > advertise label to all other nodes on the link? For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to=20 non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. Is there a specific reason to advertise adj-sid for the DR and L= AN adj-sid for non-DR? Is it because the Neighbor-ID is already part of Exte= nded link TLV and we are saving 4 bytes? =20 > I would think that we should have "route type" as in Extended prefix TLV > instead of just having a bit indicating "inter area" route-type would be misleading for range, as single range can include=20 prefixes of various types (intra, inter, external). We have discussed=20 this between authors and we agreed route-type is not the right way. The prefix range TLV is carried in Extended prefix LSA which is = based on scope of flooding. If we combine intra/inter/external in the prefix ran= ge TLV, what scope is used for flooding the extended prefix LSA? Rgds Shraddha -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Tuesday, December 02, 2014 10:39 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg Cc: OSPF WG List Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 Shraddha, please see inline: On 12/2/14 17:50 , Shraddha Hegde wrote: > Authors, > Some comments on the draft. > > 1. The draft refers to the various use cases in the use case document > in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the > section of the use case draft which is applicable for each reference > instead of giving generic reference. sure, we can add that. > 2. Section 7.2 LAN Adj-sid sub TLV: > > Based on the description of the text it appears that the LAN AdjSID=20 > Sub TLV can contain multiple neighbor-ID /SID pairs based on the nodes=20 > attached to a broadcast network. The TLV diagram should depict=20 > carrying multiple such pairs. no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor.=20 If you have more non-DR neighbors, you need to advertise multiple LAN Adj-S= ID Sub-TLVs. > "It is used to advertise a SID/Label for an > adjacency to a non-DR node on a broadcast or NBMA network." > Does the above statement mean only DR originates the LAN-Adj SIDand > advertises label to non-DR nodes? no. > Shouldn't each node in broadcast link originate LAN adj-SID and > advertise label to all other nodes on the link? For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to=20 non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. > > 3. Adj-Sid sub TLV section 7.1: > > Description of V-flag mentions Prefix-SID, it should be changed to Adj-S= ID. good catch, will correct. > > 4. Section 4: Extended prefix range TLV is very similar to Extended > prefix TLV just that it has additional range associated with it. yes, that is correct. > > I would think that we should have "route type" as in Extended prefix TLV > instead of just having a bit indicating "inter area" route-type would be misleading for range, as single range can include=20 prefixes of various types (intra, inter, external). We have discussed=20 this between authors and we agreed route-type is not the right way. thanks, Peter > Rgds > Shraddha From nobody Wed Dec 3 00:30:46 2014 Return-Path: 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 7EB921A01A9 for ; Wed, 3 Dec 2014 00:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 kJ2EzrALjyru for ; Wed, 3 Dec 2014 00:30:41 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0211A017E for ; Wed, 3 Dec 2014 00:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4344; q=dns/txt; s=iport; t=1417595441; x=1418805041; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7Kg5yB2HqmjCc0i13SqqXYPfKJFehaZysomZ8hF++l4=; b=LwWlmmFWE8OMRLgUyPNq+Ju9+yvE0HimQjgI3ys93EpkrAc2E6mfGLZ2 Q07tRmN84b8cZFUBaoMhBtWlD0C2v/UVDxyGTP5ZEq0WpY+GL2Eh/FtQD tdjXxsmgPVpqxbwudPwPicatOqXCqFTkZQDVb4ROF5EXKEeRRWjJHNHtd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAOTIflStJV2b/2dsb2JhbABbgweBK80OAoESFgEBAQEBfYQCAQEBAwE4LxEBDAQLEQQBAQEJFggHCQMCAQIBNAkIBgEMAQUCAQGIMwnWCgEBAQEBAQEBAQEBAQEBAQEBAQEBAReQbwcGhEIBBJwGgSyDOIJijVuCAiCBWj4wgkcBAQE X-IronPort-AV: E=Sophos;i="5.07,506,1413244800"; d="scan'208";a="377132352" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 03 Dec 2014 08:30:40 +0000 Received: from [10.55.51.195] (ams-ppsenak-8712.cisco.com [10.55.51.195]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB38UcHk001737; Wed, 3 Dec 2014 08:30:39 GMT Message-ID: <547ECA2E.9030808@cisco.com> Date: Wed, 03 Dec 2014 09:30:38 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> <547DF219.4020500@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ktIF2nTVC3vGYuWfcle4mQi2LWI Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 08:30:43 -0000 Shraddha, please see inline: On 12/3/14 06:10 , Shraddha Hegde wrote: > Peter, > > > >> Shouldn't each node in broadcast link originate LAN adj-SID and >> advertise label to all other nodes on the link? > > For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to > non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. > > Is there a specific reason to advertise adj-sid for the DR and LAN adj-sid for non-DR? > Is it because the Neighbor-ID is already part of Extended link TLV and we are saving 4 bytes? for adjacency on 2p2 link and adjacency to DR, link-type and link-id in Extended link TLV is used. For non-DR case, we need to describe the neighbor by neighbor-id, so we needed a new sub-TLV to do that. > > >> I would think that we should have "route type" as in Extended prefix TLV >> instead of just having a bit indicating "inter area" > > route-type would be misleading for range, as single range can include > prefixes of various types (intra, inter, external). We have discussed > this between authors and we agreed route-type is not the right way. > > The prefix range TLV is carried in Extended prefix LSA which is based on scope of flooding. > If we combine intra/inter/external in the prefix range TLV, what scope is used for flooding the extended prefix LSA? prefix range is used for SR mapping server to optimize the SID advertisement. Prefix range as such does not need to have a route type, because it is not advertising a reachability. One can use domain wide flooding for certain external prefix, but use regular inter-area distribution for prefix range that is covering the external prefix. thanks, Peter > > > Rgds > Shraddha > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Tuesday, December 02, 2014 10:39 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, > > please see inline: > > On 12/2/14 17:50 , Shraddha Hegde wrote: >> Authors, >> Some comments on the draft. >> >> 1. The draft refers to the various use cases in the use case document >> in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the >> section of the use case draft which is applicable for each reference >> instead of giving generic reference. > > sure, we can add that. > >> 2. Section 7.2 LAN Adj-sid sub TLV: >> >> Based on the description of the text it appears that the LAN AdjSID >> Sub TLV can contain multiple neighbor-ID /SID pairs based on the nodes >> attached to a broadcast network. The TLV diagram should depict >> carrying multiple such pairs. > > no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor. > If you have more non-DR neighbors, you need to advertise multiple LAN Adj-SID Sub-TLVs. > > >> "It is used to advertise a SID/Label for an >> adjacency to a non-DR node on a broadcast or NBMA network." >> Does the above statement mean only DR originates the LAN-Adj SIDand >> advertises label to non-DR nodes? > > no. > >> Shouldn't each node in broadcast link originate LAN adj-SID and >> advertise label to all other nodes on the link? > > For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to > non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. > >> >> 3. Adj-Sid sub TLV section 7.1: >> >> Description of V-flag mentions Prefix-SID, it should be changed to Adj-SID. > > good catch, will correct. > >> >> 4. Section 4: Extended prefix range TLV is very similar to Extended >> prefix TLV just that it has additional range associated with it. > > yes, that is correct. > >> >> I would think that we should have "route type" as in Extended prefix TLV >> instead of just having a bit indicating "inter area" > > route-type would be misleading for range, as single range can include > prefixes of various types (intra, inter, external). We have discussed > this between authors and we agreed route-type is not the right way. > > thanks, > Peter > >> Rgds >> Shraddha > > . > From nobody Thu Dec 4 08:46:16 2014 Return-Path: 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 085771AD4EE for ; Thu, 4 Dec 2014 08:46:15 -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 fXcExu12_a4Q for ; Thu, 4 Dec 2014 08:46:12 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D50F1AD4EA for ; Thu, 4 Dec 2014 08:45:43 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1384.namprd05.prod.outlook.com (25.160.107.142) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 4 Dec 2014 16:45:24 +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; Thu, 4 Dec 2014 16:45:24 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAOT6Fi+HUt3MSBSRa5ydDMnUARfwAAv2KAABjvTgAAB0OSAABDAJlA Date: Thu, 4 Dec 2014 16:45:24 +0000 Message-ID: References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> <547DF219.4020500@cisco.com> <547ECA2E.9030808@cisco.com> In-Reply-To: <547ECA2E.9030808@cisco.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:BY1PR0501MB1384; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1384; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(479174003)(51704005)(13464003)(24454002)(189002)(230783001)(93886004)(99286002)(107046002)(105586002)(106356001)(77156002)(62966003)(4396001)(74316001)(76576001)(21056001)(102836002)(46102003)(122556002)(40100003)(97736003)(68736005)(31966008)(101416001)(19580395003)(19580405001)(33656002)(120916001)(66066001)(99396003)(20776003)(64706001)(87936001)(2656002)(50986999)(76176999)(86362001)(54356999)(92566001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1384; 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 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/06xK0R78KjHevqrzN1t555Cj96w Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 16:46:15 -0000 Peter, > >> I would think that we should have "route type" as in Extended prefix TLV >> instead of just having a bit indicating "inter area" > > route-type would be misleading for range, as single range can include > prefixes of various types (intra, inter, external). We have discussed > this between authors and we agreed route-type is not the right way. > > The prefix range TLV is carried in Extended prefix LSA which i= s based on scope of flooding. > If we combine intra/inter/external in the prefix = range TLV, what scope is used for flooding the extended prefix LSA? prefix range is used for SR mapping server to optimize the SID=20 advertisement. Prefix range as such does not need to have a route type,=20 because it is not advertising a reachability. One can use domain wide=20 flooding for certain external prefix, but use regular inter-area=20 distribution for prefix range that is covering the external prefix. Combining the different route types in the prefix range TLV loo= ks very complex. How practical it is in a real deployment to get a p= refix range that covers through intra/inter/external route types? = =20 =20 In my opinion, it is adding unnecessary complexity i= nto the protocol. If a prefix range covers intra and inter area routes = would the IA flag be set? Would this prefix range be propagated from backbone a= rea to non-backbone area? If some prefix range contains a mix of inter and exte= rnal how's the inter area prefix SIDs=20 Propagated into NSSA area and external ones blocked? =20 Keeping the prefix ranges confined within route types = would make it much more simple. Rgds Shraddha =20 -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Wednesday, December 03, 2014 2:01 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg Cc: OSPF WG List Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 Shraddha, please see inline: On 12/3/14 06:10 , Shraddha Hegde wrote: > Peter, > > > >> Shouldn't each node in broadcast link originate LAN adj-SID=20 >> and advertise label to all other nodes on the link? > > For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to=20 > non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. > > Is there a specific reason to advertise adj-sid for the DR and= LAN adj-sid for non-DR? > Is it because the Neighbor-ID is already part of E= xtended link TLV and we are saving 4 bytes? for adjacency on 2p2 link and adjacency to DR, link-type and link-id in Ext= ended link TLV is used. For non-DR case, we need to describe the neighbor b= y neighbor-id, so we needed a new sub-TLV to do that. > > >> I would think that we should have "route type" as in Extended prefix TLV >> instead of just having a bit indicating "inter area" > > route-type would be misleading for range, as single range can include > prefixes of various types (intra, inter, external). We have discussed > this between authors and we agreed route-type is not the right way. > > The prefix range TLV is carried in Extended prefix LSA which i= s based on scope of flooding. > If we combine intra/inter/external in the prefix = range TLV, what scope is used for flooding the extended prefix LSA? prefix range is used for SR mapping server to optimize the SID=20 advertisement. Prefix range as such does not need to have a route type,=20 because it is not advertising a reachability. One can use domain wide=20 flooding for certain external prefix, but use regular inter-area=20 distribution for prefix range that is covering the external prefix. thanks, Peter > > > Rgds > Shraddha > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Tuesday, December 02, 2014 10:39 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, > > please see inline: > > On 12/2/14 17:50 , Shraddha Hegde wrote: >> Authors, >> Some comments on the draft. >> >> 1. The draft refers to the various use cases in the use case document >> in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the >> section of the use case draft which is applicable for each referenc= e >> instead of giving generic reference. > > sure, we can add that. > >> 2. Section 7.2 LAN Adj-sid sub TLV: >> >> Based on the description of the text it appears that the LAN AdjSID >> Sub TLV can contain multiple neighbor-ID /SID pairs based on the nodes >> attached to a broadcast network. The TLV diagram should depict >> carrying multiple such pairs. > > no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor. > If you have more non-DR neighbors, you need to advertise multiple LAN Adj= -SID Sub-TLVs. > > >> "It is used to advertise a SID/Label for an >> adjacency to a non-DR node on a broadcast or NBMA network." >> Does the above statement mean only DR originates the LAN-Adj SIDand >> advertises label to non-DR nodes? > > no. > >> Shouldn't each node in broadcast link originate LAN adj-SID and >> advertise label to all other nodes on the link? > > For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to > non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. > >> >> 3. Adj-Sid sub TLV section 7.1: >> >> Description of V-flag mentions Prefix-SID, it should be changed to Adj-= SID. > > good catch, will correct. > >> >> 4. Section 4: Extended prefix range TLV is very similar to Extended >> prefix TLV just that it has additional range associated with it. > > yes, that is correct. > >> >> I would think that we should have "route type" as in Extended prefix TLV >> instead of just having a bit indicating "inter area" > > route-type would be misleading for range, as single range can include > prefixes of various types (intra, inter, external). We have discussed > this between authors and we agreed route-type is not the right way. > > thanks, > Peter > >> Rgds >> Shraddha > > . > From nobody Thu Dec 4 09:45:29 2014 Return-Path: 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 5BDE81A6FC4 for ; Thu, 4 Dec 2014 09:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 7xDrrMHymce7 for ; Thu, 4 Dec 2014 09:45:25 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FCD1A1BBB for ; Thu, 4 Dec 2014 09:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7518; q=dns/txt; s=iport; t=1417715125; x=1418924725; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uTgxofitIS3sirT2Bg9tAqTQIrRYjpbP5hj8sOd0rug=; b=mIpRIB7xKoevFCX7gSbqMH4BNAerf0zLS2SDcb2lyQpod4Z8W52/xBXf RgNWFMEIcF5/Mi7EBQGk+LFpPORTVyXIWJ0srNIGbaxZGoH9iL+anKoAO XHTCEpYGGtEZzFaQethzmk1sOvsFfsR01pJYNRDOKuRNVDlExC6e5+wjv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAH2cgFStJV2d/2dsb2JhbABZgwaBKsxqAoEeFgEBAQEBfYQCAQEBAwE4LxEBBQcECxEEAQEBCRYIBwkDAgECATQJCAYBDAEFAgEBiDEJ1yYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkGYHBoQ8AQSaWoEjgy2CTYx7ggAggVo+MIJFAQEB X-IronPort-AV: E=Sophos;i="5.07,517,1413244800"; d="scan'208";a="377621569" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 04 Dec 2014 17:45:24 +0000 Received: from [10.55.51.195] (ams-ppsenak-8712.cisco.com [10.55.51.195]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB4HjMJu004802; Thu, 4 Dec 2014 17:45:23 GMT Message-ID: <54809DB4.4060407@cisco.com> Date: Thu, 04 Dec 2014 18:45:24 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> <547DF219.4020500@cisco.com> <547ECA2E.9030808@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/7o1gyje2mwE67HJ5pLGzcWRmrUI Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:45:27 -0000 Shraddha, On 12/4/14 17:45 , Shraddha Hegde wrote: > > Peter, > >> >>> I would think that we should have "route type" as in Extended prefix TLV >>> instead of just having a bit indicating "inter area" >> >> route-type would be misleading for range, as single range can include >> prefixes of various types (intra, inter, external). We have discussed >> this between authors and we agreed route-type is not the right way. >> >> The prefix range TLV is carried in Extended prefix LSA which is based on scope of flooding. >> If we combine intra/inter/external in the prefix range TLV, what scope is used for flooding the extended prefix LSA? > > prefix range is used for SR mapping server to optimize the SID > advertisement. Prefix range as such does not need to have a route type, > because it is not advertising a reachability. One can use domain wide > flooding for certain external prefix, but use regular inter-area > distribution for prefix range that is covering the external prefix. > > > Combining the different route types in the prefix range TLV looks very complex. > How practical it is in a real deployment to get a prefix range that covers through intra/inter/external route types? Imagine you want to advertise a SIDs for a range 192.0.2.1, Prefix Length 32, Range Size 255. Out of that range individual /32 prefixes can be of different route-types. Prefix range does not have a route-type. > > In my opinion, it is adding unnecessary complexity into the protocol. > If a prefix range covers intra and inter area routes would the IA flag be set? IA flag has nothing to do with the route-type. IA flag means that the range advertisement has bean 'leaked' between areas and is used to prevent redundant leaking. > Would this prefix range be propagated from backbone area to non-backbone area? yes, SRMS range advertisements will be propagated between areas if LSA type 10 is used for the advertisement. > If some prefix range contains a mix of inter and external how's the inter area prefix SIDs > Propagated into NSSA area and external ones blocked? that is not a problem. You may not have external prefix in NSSA area, but the range can still cover such external prefix. In such case the SID for the external prefix will never be used in NSSA area. > > Keeping the prefix ranges confined within route types would make it much more simple. true, but it will make the deployment harder. thanks, Peter > > Rgds > Shraddha > > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, December 03, 2014 2:01 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, > > please see inline: > > On 12/3/14 06:10 , Shraddha Hegde wrote: >> Peter, >> >> >> >>> Shouldn't each node in broadcast link originate LAN adj-SID >>> and advertise label to all other nodes on the link? >> >> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to >> non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. >> >> Is there a specific reason to advertise adj-sid for the DR and LAN adj-sid for non-DR? >> Is it because the Neighbor-ID is already part of Extended link TLV and we are saving 4 bytes? > > for adjacency on 2p2 link and adjacency to DR, link-type and link-id in Extended link TLV is used. For non-DR case, we need to describe the neighbor by neighbor-id, so we needed a new sub-TLV to do that. > >> >> >>> I would think that we should have "route type" as in Extended prefix TLV >>> instead of just having a bit indicating "inter area" >> >> route-type would be misleading for range, as single range can include >> prefixes of various types (intra, inter, external). We have discussed >> this between authors and we agreed route-type is not the right way. >> >> The prefix range TLV is carried in Extended prefix LSA which is based on scope of flooding. >> If we combine intra/inter/external in the prefix range TLV, what scope is used for flooding the extended prefix LSA? > > prefix range is used for SR mapping server to optimize the SID > advertisement. Prefix range as such does not need to have a route type, > because it is not advertising a reachability. One can use domain wide > flooding for certain external prefix, but use regular inter-area > distribution for prefix range that is covering the external prefix. > > thanks, > Peter > >> >> >> Rgds >> Shraddha >> >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Tuesday, December 02, 2014 10:39 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, >> >> please see inline: >> >> On 12/2/14 17:50 , Shraddha Hegde wrote: >>> Authors, >>> Some comments on the draft. >>> >>> 1. The draft refers to the various use cases in the use case document >>> in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the >>> section of the use case draft which is applicable for each reference >>> instead of giving generic reference. >> >> sure, we can add that. >> >>> 2. Section 7.2 LAN Adj-sid sub TLV: >>> >>> Based on the description of the text it appears that the LAN AdjSID >>> Sub TLV can contain multiple neighbor-ID /SID pairs based on the nodes >>> attached to a broadcast network. The TLV diagram should depict >>> carrying multiple such pairs. >> >> no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor. >> If you have more non-DR neighbors, you need to advertise multiple LAN Adj-SID Sub-TLVs. >> >> >>> "It is used to advertise a SID/Label for an >>> adjacency to a non-DR node on a broadcast or NBMA network." >>> Does the above statement mean only DR originates the LAN-Adj SIDand >>> advertises label to non-DR nodes? >> >> no. >> >>> Shouldn't each node in broadcast link originate LAN adj-SID and >>> advertise label to all other nodes on the link? >> >> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to >> non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. >> >>> >>> 3. Adj-Sid sub TLV section 7.1: >>> >>> Description of V-flag mentions Prefix-SID, it should be changed to Adj-SID. >> >> good catch, will correct. >> >>> >>> 4. Section 4: Extended prefix range TLV is very similar to Extended >>> prefix TLV just that it has additional range associated with it. >> >> yes, that is correct. >> >>> >>> I would think that we should have "route type" as in Extended prefix TLV >>> instead of just having a bit indicating "inter area" >> >> route-type would be misleading for range, as single range can include >> prefixes of various types (intra, inter, external). We have discussed >> this between authors and we agreed route-type is not the right way. >> >> thanks, >> Peter >> >>> Rgds >>> Shraddha >> >> . >> > > . > From nobody Thu Dec 4 14:03:01 2014 Return-Path: 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 6F1641A6FE1; Thu, 4 Dec 2014 14:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 SehWb_xCy1uP; Thu, 4 Dec 2014 14:02:46 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7F81A1B8C; Thu, 4 Dec 2014 14:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10625; q=dns/txt; s=iport; t=1417730567; x=1418940167; h=from:to:cc:subject:date:message-id:mime-version; bh=++kzOTgBp3UrfnqsloEb2qp729pgqRO5RD8YTkkG6gE=; b=Y/gvR9MtWOXPgPrXd0i51mZV1Q6GHQ2Fuad9ryr6Fm4wQh7GnpYMf6Dt OKvuKnNsz7wjewBZ4fNJkln3fByw3RhxhaOSTo0rE2hBv3tIlQvaZ/GVW ls5kOCA7DKkz0L5gOEKIMGDu8Kn1HKcc13kBC2vdWEM79+cTMCW6r6g5q E=; X-Files: iesg-writeup-draft-ietf-ospf-te-metric-extensions.txt : 7086 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAPHYgFStJA2E/2dsb2JhbABPCoMGUlkDxlGGFIEkFgEBAQEBfYQJawMEBxIBNRswJwQBDQ4FDYgjDdcnAQEBAQEBAQEBAQEBAQEBAQEBGpAEBgsBUBGEOAWOGoF2gXaCIIY0gSODLY9Ig3mBdAcXBhyBAAEBAQ X-IronPort-AV: E=Sophos;i="5.07,518,1413244800"; d="txt'?scan'208";a="102797893" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 04 Dec 2014 22:02:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB4M2jmv012351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 22:02:45 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 16:02:45 -0600 From: "Acee Lindem (acee)" To: "ospf-chairs@tools.ietf.org" , Routing ADs , OSPF WG List , IESG Secretary Thread-Topic: Publication Request for "OSPF Traffic Engineering (TE) Metric Extensions" Thread-Index: AQHQEA4ImVhrZChNpUKJs5isMcOWBg== Date: Thu, 4 Dec 2014 22:02:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.199] Content-Type: multipart/mixed; boundary="_002_D0A64433A159aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/UFJ-NDwHJkBMs0gk2fBa_Slc5V4 Cc: "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" Subject: [OSPF] Publication Request for "OSPF Traffic Engineering (TE) Metric Extensions" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 22:02:53 -0000 --_002_D0A64433A159aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <8AF7CF003F5B0E489B8409CD8AE89849@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Please publish draft-ietf-ospf-te-metric-extensions-08.txt as a standards track document.=20 I am the document shepherd and have attached the IESG writeup. Thanks, Acee=20 --_002_D0A64433A159aceeciscocom_ Content-Type: text/plain; name="iesg-writeup-draft-ietf-ospf-te-metric-extensions.txt" Content-Description: iesg-writeup-draft-ietf-ospf-te-metric-extensions.txt Content-Disposition: attachment; filename="iesg-writeup-draft-ietf-ospf-te-metric-extensions.txt"; size=7086; creation-date="Thu, 04 Dec 2014 22:02:45 GMT"; modification-date="Thu, 04 Dec 2014 22:02:45 GMT" Content-ID: Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLCBJbnRlcm5ldA0KICAgIFN0YW5kYXJkLCBJbmZvcm1hdGlvbmFsLCBFeHBlcmltZW50 YWwsIG9yIEhpc3RvcmljKT8gV2h5IGlzIHRoaXMgdGhlDQogICAgcHJvcGVyIHR5cGUgb2YgUkZD PyBJcyB0aGlzIHR5cGUgb2YgUkZDIGluZGljYXRlZCBpbiB0aGUgdGl0bGUgcGFnZQ0KICAgIGhl YWRlcj8NCg0KICAgICAgQSBTdGFuZGFyZHMgVHJhY2sgUkZDIGlzIGJlaW5nIHJlcXVlc3RlZCBh bmQgaXMgaW5kaWNhdGVkIGluIHRoZQ0KICAgICAgdGl0bGUgcGFnZSBoZWFkZXIuDQoNCigyKSBU aGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCBBbm5vdW5j ZW1lbnQNCiAgICBXcml0ZS1VcC4gIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCBBbm5v dW5jZW1lbnQgV3JpdGUtVXAuDQogICAgUmVjZW50IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0 aGUgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3INCiAgICBhcHByb3ZlZCBkb2N1bWVudHMuIFRo ZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2luZw0KICAgIHNlY3Rp b25zOg0KDQpUZWNobmljYWwgU3VtbWFyeToNCg0KICAgICAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgZXh0ZW5zaW9ucyB0byBPU1BGIFRyYWZmaWMgRW5naW5lZXJpbmcgDQogICAgICB0byBpbmNs dWRlIGRlbGF5LCBsb3NzLCBhbmQgY3VycmVudCBiYW5kd2lkdGggdXRpbGl6YXRpb24gbWV0cmlj IA0KICAgICAgdGhhdCBjYW4gYmUgdGFrZW4gaW50byBhY2NvdW50IHdoZW4gcGVyZm9ybWluZyB0 cmFmZmljIGVuZ2luZWVyaW5nLiANCg0KV29ya2luZyBHcm91cCBTdW1tYXJ5Og0KDQogICAgICBU aGVyZSBoYXMgYmVlbiBtdWNoIGRpc2N1c3NvbiBhcyB0byBob3cgdGhlc2UgbWV0cmljcyB3b3Vs ZCBiZSANCiAgICAgIGNvbGxlY3RlZCBhbmQgaG93IHRoZXkgd2lsbCBiZSB1c2VkLiBUaGVzZSB0 b3BpY3Mgd2VyZSBkZWVtZWQgdG8gDQogICAgICB0byBiZSBvdXQgb2Ygc2NvcGUuIA0KDQogICAg ICBUaGVyZSB3YXMgYWxzbyBjb25jZXJuIGZvciBwb3RlbnRpYWwgb3ZlcmhlYWQgb2YgY29sbGVj dGluZw0KICAgICAgYW5kIGZsb29kaW5nIHRoZXNlIG1ldHJpY3MuIEluIHJlc3BvbnNlLCB0aGUg ZHJhZnQgY29udGFpbnMgDQogICAgICBndWlkYW5jZSBhcyB0byBob3cgb2Z0ZW4gdGhlIG1lYXN1 cmVtZW50cyBzaG91bGQgYmUgY29sbGVjdGVkIGFuZA0KICAgICAgZmxvb2RlZC4gQWRkaXRpb25h bGx5LCB0aGUgZHJhZnQgbm93IHJlY29tbWVuZHMgY29uZmlndXJhdGlvbg0KICAgICAgdG8gY29u dHJvbCBtZWFzdXJlbWVudCB1c2FnZSBhbmQgdGhlIHRocmVzaG9sZHMgZm9yIGFkdmVydGlzZW1l bnQuIA0KDQogICAgICBGaW5hbGx5LCB0aGUgZHJhZnQgd2FzIHVwZGF0ZWQgdG8gaW5jbHVkZSBh cHBsaWNhYmlsaXR5IHRvIA0KICAgICAgQWR2YW5jZWQgTXVsdGlwYXRoIGxpbmtzLiANCg0KRG9j dW1lbnQgUXVhbGl0eToNCg0KICAgICAgVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBhIFdHIGRvY3Vt ZW50IGZvciBhIGxpdHRsZSB1bmRlciB0d28geWVhcnMuDQogICAgICBJdCBpcyBzdGFibGUsIHdp dGhvdXQgY2hhbmdlcyB0byB0aGUgdGVjaG5pY2FsIHNvbHV0aW9uIGZvciBtb3JlDQogICAgICB0 aGFuIHNpeCBtb250aHMuIA0KDQpQZXJzb25uZWw6DQoNCiAgICAgIEFjZWUgTGluZGVtIGlzIHRo ZSBEb2N1bWVudCBTaGVwaGVyZC4NCiAgICAgIEFsaWEgQXRsYXMgaXMgdGhlIFJlc3BvbnNpYmxl IEFyZWEgRGlyZWN0b3IuDQoNCigzKSBCcmllZmx5IGRlc2NyaWJlIHRoZSByZXZpZXcgb2YgdGhp cyBkb2N1bWVudCB0aGF0IHdhcyBwZXJmb3JtZWQgYnkNCiAgICB0aGUgRG9jdW1lbnQgU2hlcGhl cmQuIElmIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgaXMgbm90IHJlYWR5DQogICAgZm9y IHB1YmxpY2F0aW9uLCBwbGVhc2UgZXhwbGFpbiB3aHkgdGhlIGRvY3VtZW50IGlzIGJlaW5nIGZv cndhcmRlZA0KICAgIHRvIHRoZSBJRVNHLg0KDQogICAgIFRoZSBkb2N1bWVudCBzaGVwaGVyZCBo YXMgcmV2aWV3ZWQgZWFjaCByZXZpc2lvbiBvZiB0aGUgZG9jdW1lbnQNCiAgICAgYW5kIGZvbGxv d2VkIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBPU1BGIG1haWxpbmcgbGlzdC4gDQoNCg0KKDQpIERv ZXMgdGhlIGRvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0 aCBvcg0KICAgIGJyZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCBoYXZlIGJlZW4gcGVyZm9ybWVk Pw0KDQogICAgICBOby4NCg0KKDUpIERvIHBvcnRpb25zIG9mIHRoZSBkb2N1bWVudCBuZWVkIHJl dmlldyBmcm9tIGEgcGFydGljdWxhciBvciBmcm9tDQogICAgYnJvYWRlciBwZXJzcGVjdGl2ZSwg ZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIEFBQSwNCiAgICBETlMsIERI Q1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/IElmIHNvLCBkZXNjcmliZSB0aGUgcmV2 aWV3DQogICAgdGhhdCB0b29rIHBsYWNlLg0KDQogICAgICBOby4NCg0KKDYpIERlc2NyaWJlIGFu eSBzcGVjaWZpYyBjb25jZXJucyBvciBpc3N1ZXMgdGhhdCB0aGUgRG9jdW1lbnQgU2hlcGhlcmQN CiAgICBoYXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGly ZWN0b3IgYW5kL29yDQogICAgdGhlIElFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3IgZXhhbXBs ZSwgcGVyaGFwcyBoZSBvciBzaGUgaXMNCiAgICB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFpbiBw YXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIGhhcyBjb25jZXJucw0KICAgIHdoZXRoZXIgdGhlcmUg cmVhbGx5IGlzIGEgbmVlZCBmb3IgaXQuIEluIGFueSBldmVudCwgaWYgdGhlIFdHIGhhcw0KICAg IGRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3 aXNoZXMgdG8NCiAgICBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlIGNvbmNlcm5z IGhlcmUuDQoNCiAgICAgIE5vbmUuDQoNCig3KSBIYXMgZWFjaCBhdXRob3IgY29uZmlybWVkIHRo YXQgYW55IGFuZCBhbGwgYXBwcm9wcmlhdGUgSVBSDQogICAgZGlzY2xvc3VyZXMgcmVxdWlyZWQg Zm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1ANCiAgICA3OCBh bmQgQkNQIDc5IGhhdmUgYWxyZWFkeSBiZWVuIGZpbGVkLiBJZiBub3QsIGV4cGxhaW4gd2h5Pw0K DQogICAgIFllcy4NCg0KKDgpIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVkIHRoYXQg cmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50PyBJZg0KICAgIHNvLCBzdW1tYXJpemUgYW55IFdHIGRp c2N1c3Npb24gYW5kIGNvbmNsdXNpb24gcmVnYXJkaW5nIHRoZSBJUFINCiAgICBkaXNjbG9zdXJl cy4NCg0KICAgICAgWWVzLiANCg0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvc2VhcmNoLz9vcHRpb249ZG9jdW1lbnRfc2VhcmNoJmlkPWRyYWZ0LWlldGYtb3NwZi10ZS1t ZXRyaWMtZXh0ZW5zaW9ucw0KDQogICAgICBUaGVyZSB3YXNuJ3QgYW55IGRpc2N1c3Npb24uIElQ UiBvbiBkcmFmdHMgaXMgcXVpdGUgY29tbW9uLg0KDQooOSkgSG93IHNvbGlkIGlzIHRoZSBXRyBj b25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/IERvZXMgaXQNCiAgICByZXByZXNlbnQgdGhl IHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCBvdGhlcnMNCiAg ICBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQg YWdyZWUgd2l0aCBpdD8NCg0KICAgICAgVGhlcmUgaXMgY29uc2Vuc3VzIGZyb20gdGhlIFdHIGFu ZCBvdGhlcnMgb3V0c2lkZSB0aGUgV0cgdGhhdA0KICAgICAgdGhpcyBkb2N1bWVudCBjYW4gcHJv Z3Jlc3MuIA0KDQooMTApIEhhcyBhbnlvbmUgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3 aXNlIGluZGljYXRlZCBleHRyZW1lDQogICAgIGRpc2NvbnRlbnQ/ICBJZiBzbywgcGxlYXNlIHN1 bW1hcmlzZSB0aGUgYXJlYXMgb2YgY29uZmxpY3QgaW4NCiAgICAgc2VwYXJhdGUgZW1haWwgbWVz c2FnZXMgdG8gdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuIChJdA0KICAgICBzaG91bGQg YmUgaW4gYSBzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcw0KICAg ICBwdWJsaWNseSBhdmFpbGFibGUuKQ0KDQogICAgICBOby4NCg0KKDExKSBJZGVudGlmeSBhbnkg SUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZvdW5kIGluIHRoaXMNCiAgICAgZG9j dW1lbnQuICAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLyBhbmQgdGhlDQog ICAgIEludGVybmV0LURyYWZ0cyBDaGVja2xpc3QpLiAgQm9pbGVycGxhdGUgY2hlY2tzIGFyZSBu b3QgZW5vdWdoOw0KICAgICB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlIHRob3JvdWdoLg0KDQogICAg ICBOaXRzIGFyZSBhbGwgcmVzb2x2ZWQuIA0KDQooMTIpIERlc2NyaWJlIGhvdyB0aGUgZG9jdW1l bnQgbWVldHMgYW55IHJlcXVpcmVkIGZvcm1hbCByZXZpZXcNCiAgICAgY3JpdGVyaWEsIHN1Y2gg YXMgdGhlIE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzLg0KDQog ICAgICBOb3QgYXBwbGljYWJsZS4NCg0KKDEzKSBIYXZlIGFsbCByZWZlcmVuY2VzIHdpdGhpbiB0 aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRpZmllZCBhcyBlaXRoZXINCiAgICAgbm9ybWF0aXZlIG9y IGluZm9ybWF0aXZlPw0KDQogICAgICBZZXMuDQoNCigxNCkgQXJlIHRoZXJlIG5vcm1hdGl2ZSBy ZWZlcmVuY2VzIHRvIGRvY3VtZW50cyB0aGF0IGFyZSBub3QgcmVhZHkgZm9yDQogICAgIGFkdmFu Y2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBzdGF0ZT8gSWYgc3VjaA0KICAg ICBub3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgcGxhbiBmb3IgdGhlaXIg Y29tcGxldGlvbj8NCiAgDQogICAgICBOby4NCg0KKDE1KSBBcmUgdGhlcmUgZG93bndhcmQgbm9y bWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT8NCiAgICAgSWYgc28s IGxpc3QgdGhlc2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhIERpcmVj dG9yDQogICAgIGluIHRoZSBMYXN0IENhbGwgcHJvY2VkdXJlLg0KDQogICAgICBOby4NCg0KKDE2 KSBXaWxsIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgY2hhbmdlIHRoZSBzdGF0dXMgb2Yg YW55IGV4aXN0aW5nDQogICAgIFJGQ3M/ICBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQgb24gdGhlIHRp dGxlIHBhZ2UgaGVhZGVyLCBsaXN0ZWQgaW4NCiAgICAgdGhlIGFic3RyYWN0LCBhbmQgZGlzY3Vz c2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZQ0KICAgICBub3QgbGlzdGVk IGluIHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uLCBleHBsYWluIHdoeSwgYW5kIHBvaW50 DQogICAgIHRvIHRoZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCB3aGVyZSB0aGUgcmVsYXRpb25zaGlw IG9mIHRoaXMgZG9jdW1lbnQNCiAgICAgdG8gdGhlIG90aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJ ZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUNCiAgICAgZG9jdW1lbnQsIGV4cGxhaW4g d2h5IHRoZSBXRyBjb25zaWRlcnMgaXQgdW5uZWNlc3NhcnkuDQoNCiAgICAgIE5vLg0KDQooMTcp IERlc2NyaWJlIHRoZSBEb2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSBjb25z aWRlcmF0aW9ucw0KICAgICBzZWN0aW9uLCBlc3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyBj b25zaXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9mDQogICAgIHRoZSBkb2N1bWVudC4gIENvbmZpcm0g dGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0IHRoZQ0KICAgICBkb2N1bWVudCBtYWtl cyBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBhcHByb3ByaWF0ZSByZXNlcnZhdGlvbnMgaW4NCiAg ICAgSUFOQSByZWdpc3RyaWVzLiBDb25maXJtIHRoYXQgYW55IHJlZmVyZW5jZWQgSUFOQSByZWdp c3RyaWVzIGhhdmUNCiAgICAgYmVlbiBjbGVhcmx5IGlkZW50aWZpZWQuIENvbmZpcm0gdGhhdCBu ZXdseSBjcmVhdGVkIElBTkEgcmVnaXN0cmllcw0KICAgICBpbmNsdWRlIGEgZGV0YWlsZWQgc3Bl Y2lmaWNhdGlvbiBvZiB0aGUgaW5pdGlhbCBjb250ZW50cyBmb3IgdGhlDQogICAgIHJlZ2lzdHJ5 LCB0aGF0IGFsbG9jYXRpb25zIHByb2NlZHVyZXMgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zIGFy ZQ0KICAgICBkZWZpbmVkLCBhbmQgYSByZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0 cnkgaGFzIGJlZW4NCiAgICAgc3VnZ2VzdGVkIChzZWUgUkZDIDUyMjYpLg0KICANCiAgICAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBzZXZlbiBuZXcgT1NQRiBUcmFmZmljIEVuZ2luZWVyaW5nIHN1 Yi1UTFZzDQogICAgICB0aGF0IGFyZSBhcHBsaWNhYmxlIHRvIHRoZSBPU1BGIFRFIExpbmsgVExW Lg0KDQooMTgpIExpc3QgYW55IG5ldyBJQU5BIHJlZ2lzdHJpZXMgdGhhdCByZXF1aXJlIEV4cGVy dCBSZXZpZXcgZm9yIGZ1dHVyZQ0KICAgICBhbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkgcHVibGlj IGd1aWRhbmNlIHRoYXQgdGhlIElFU0cgd291bGQgZmluZA0KICAgICB1c2VmdWwgaW4gc2VsZWN0 aW5nIHRoZSBJQU5BIEV4cGVydHMgZm9yIHRoZXNlIG5ldyByZWdpc3RyaWVzLg0KDQogICAgICBO b25lLiANCg0KKDE5KSBEZXNjcmliZSByZXZpZXdzIGFuZCBhdXRvbWF0ZWQgY2hlY2tzIHBlcmZv cm1lZCBieSB0aGUgRG9jdW1lbnQNCiAgICAgU2hlcGhlcmQgdG8gdmFsaWRhdGUgc2VjdGlvbnMg b2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gaW4gYSBmb3JtYWwNCiAgICAgbGFuZ3VhZ2UsIHN1Y2gg YXMgWE1MIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuDQogDQogICAgICBO b3QgYXBwbGljYWJsZS4NCg0K --_002_D0A64433A159aceeciscocom_-- From nobody Thu Dec 4 20:52:40 2014 Return-Path: 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 904211AC3F0 for ; Thu, 4 Dec 2014 20:52:38 -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, 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 4JLDmk3cYrQ7 for ; Thu, 4 Dec 2014 20:52:35 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731781AC3EE for ; Thu, 4 Dec 2014 20:52:35 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1382.namprd05.prod.outlook.com (25.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 5 Dec 2014 04:52:12 +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; Fri, 5 Dec 2014 04:52:12 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAOT6Fi+HUt3MSBSRa5ydDMnUARfwAAv2KAABjvTgAAB0OSAABDAJlAAAKqAQAAFvCLYA== Date: Fri, 5 Dec 2014 04:52:11 +0000 Message-ID: References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> <547DF219.4020500@cisco.com> <547ECA2E.9030808@cisco.com> <54809DB4.4060407@cisco.com> In-Reply-To: <54809DB4.4060407@cisco.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:BY1PR0501MB1382; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1382; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(24454002)(479174003)(377454003)(189002)(51704005)(66066001)(62966003)(20776003)(64706001)(93886004)(122556002)(99286002)(46102003)(106356001)(230783001)(54206007)(99396003)(120916001)(92566001)(86362001)(77156002)(105586002)(74316001)(40100003)(2656002)(21056001)(68736005)(87936001)(33656002)(76576001)(19580405001)(4396001)(54606007)(54356999)(19580395003)(107046002)(97736003)(76176999)(50986999)(31966008)(101416001)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1382; 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 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/bXMDedRoRFMj5ZSNjDEkFWEuegU Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 04:52:38 -0000 Peter, > Would this prefix range be propagated from backbon= e area to non-backbone area? yes, SRMS range advertisements will be propagated between areas if LSA type= 10 is used for the advertisement. You mean area scope (type 10) LSAs will be flooded across area b= oundary? Or you mean they will be Re-originated at the boundary and if AS scope LSA (t= ype 11) they will be flooded across the boundary? > > Keeping the prefix ranges confined within route typ= es would make it much more simple. true, but it will make the deployment harder. OK. I see your point. I think the document needs to capture the information that the prefix range= can have different route-types covered. It wasn't clear from reading the document. Probably an "elements of proced= ure" section is required for the prefix range TLV To cover the flooding scope and other aspects. One more point to be mentioned is that if there is a prefix range TLV that = covers a certain prefix and there is also a prefix SID For the same prefix , then the prefix SID should be considered and the SID = in the prefix range should be ignored. Rgds Shraddha -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Thursday, December 04, 2014 11:15 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg Cc: OSPF WG List Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 Shraddha, On 12/4/14 17:45 , Shraddha Hegde wrote: > > Peter, > >> >>> I would think that we should have "route type" as in Extended prefix=20 >>> TLV instead of just having a bit indicating "inter area" >> >> route-type would be misleading for range, as single range can include=20 >> prefixes of various types (intra, inter, external). We have discussed=20 >> this between authors and we agreed route-type is not the right way. >> >> The prefix range TLV is carried in Extended prefix LSA which = is based on scope of flooding. >> If we combine intra/inter/external in the prefi= x range TLV, what scope is used for flooding the extended prefix LSA? > > prefix range is used for SR mapping server to optimize the SID=20 > advertisement. Prefix range as such does not need to have a route=20 > type, because it is not advertising a reachability. One can use domain=20 > wide flooding for certain external prefix, but use regular inter-area=20 > distribution for prefix range that is covering the external prefix. > > > Combining the different route types in the prefix range TLV l= ooks very complex. > How practical it is in a real deployment to get = a prefix range that covers through intra/inter/external route types? Imagine you want to advertise a SIDs for a range 192.0.2.1, Prefix Length 3= 2, Range Size 255. Out of that range individual /32 prefixes can be of diff= erent route-types. Prefix range does not have a route-type. > > In my opinion, it is adding unnecessary complexit= y into the protocol. > If a prefix range covers intra and inter area rout= es would the IA flag be set? IA flag has nothing to do with the route-type. IA flag means that the range= advertisement has bean 'leaked' between areas and is used to prevent redun= dant leaking. > Would this prefix range be propagated from backbon= e area to non-backbone area? yes, SRMS range advertisements will be propagated between areas if LSA type= 10 is used for the advertisement. > If some prefix range contains a mix of inter and e= xternal how's the inter area prefix SIDs > Propagated into NSSA area and external ones blocke= d? that is not a problem. You may not have external prefix in NSSA area, but t= he range can still cover such external prefix. In such case the SID for the= external prefix will never be used in NSSA area. > > Keeping the prefix ranges confined within route typ= es would make it much more simple. true, but it will make the deployment harder. thanks, Peter > > Rgds > Shraddha > > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, December 03, 2014 2:01 PM > To: Shraddha Hegde;=20 > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org > Cc: OSPF WG List > Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 > > Shraddha, > > please see inline: > > On 12/3/14 06:10 , Shraddha Hegde wrote: >> Peter, >> >> >> >>> Shouldn't each node in broadcast link originate LAN adj-SID=20 >>> and advertise label to all other nodes on the link? >> >> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency=20 >> to non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LA= N. >> >> Is there a specific reason to advertise adj-sid for the DR an= d LAN adj-sid for non-DR? >> Is it because the Neighbor-ID is already part of= Extended link TLV and we are saving 4 bytes? > > for adjacency on 2p2 link and adjacency to DR, link-type and link-id in E= xtended link TLV is used. For non-DR case, we need to describe the neighbor= by neighbor-id, so we needed a new sub-TLV to do that. > >> >> >>> I would think that we should have "route type" as in Extended prefix=20 >>> TLV instead of just having a bit indicating "inter area" >> >> route-type would be misleading for range, as single range can include=20 >> prefixes of various types (intra, inter, external). We have discussed=20 >> this between authors and we agreed route-type is not the right way. >> >> The prefix range TLV is carried in Extended prefix LSA which = is based on scope of flooding. >> If we combine intra/inter/external in the prefi= x range TLV, what scope is used for flooding the extended prefix LSA? > > prefix range is used for SR mapping server to optimize the SID=20 > advertisement. Prefix range as such does not need to have a route=20 > type, because it is not advertising a reachability. One can use domain=20 > wide flooding for certain external prefix, but use regular inter-area=20 > distribution for prefix range that is covering the external prefix. > > thanks, > Peter > >> >> >> Rgds >> Shraddha >> >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Tuesday, December 02, 2014 10:39 PM >> To: Shraddha Hegde;=20 >> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org >> Cc: OSPF WG List >> Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 >> >> Shraddha, >> >> please see inline: >> >> On 12/2/14 17:50 , Shraddha Hegde wrote: >>> Authors, >>> Some comments on the draft. >>> >>> 1. The draft refers to the various use cases in the use case documen= t >>> in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the >>> section of the use case draft which is applicable for each refere= nce >>> instead of giving generic reference. >> >> sure, we can add that. >> >>> 2. Section 7.2 LAN Adj-sid sub TLV: >>> >>> Based on the description of the text it appears that the LAN AdjSID=20 >>> Sub TLV can contain multiple neighbor-ID /SID pairs based on the=20 >>> nodes attached to a broadcast network. The TLV diagram should depict=20 >>> carrying multiple such pairs. >> >> no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor. >> If you have more non-DR neighbors, you need to advertise multiple LAN Ad= j-SID Sub-TLVs. >> >> >>> "It is used to advertise a SID/Label for an >>> adjacency to a non-DR node on a broadcast or NBMA network." >>> Does the above statement mean only DR originates the LAN-Adj SIDand=20 >>> advertises label to non-DR nodes? >> >> no. >> >>> Shouldn't each node in broadcast link originate LAN adj-SID=20 >>> and advertise label to all other nodes on the link? >> >> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency=20 >> to non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LA= N. >> >>> >>> 3. Adj-Sid sub TLV section 7.1: >>> >>> Description of V-flag mentions Prefix-SID, it should be changed to Adj= -SID. >> >> good catch, will correct. >> >>> >>> 4. Section 4: Extended prefix range TLV is very similar to Extended >>> prefix TLV just that it has additional range associated with it. >> >> yes, that is correct. >> >>> >>> I would think that we should have "route type" as in Extended prefix=20 >>> TLV instead of just having a bit indicating "inter area" >> >> route-type would be misleading for range, as single range can include=20 >> prefixes of various types (intra, inter, external). We have discussed=20 >> this between authors and we agreed route-type is not the right way. >> >> thanks, >> Peter >> >>> Rgds >>> Shraddha >> >> . >> > > . > From nobody Fri Dec 5 00:08:55 2014 Return-Path: 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 D4A551AC44E for ; Fri, 5 Dec 2014 00:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Dkj4Jz3Tnb6r for ; Fri, 5 Dec 2014 00:08:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7759D1A00F0 for ; Fri, 5 Dec 2014 00:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9518; q=dns/txt; s=iport; t=1417766889; x=1418976489; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0I6b5DaefhFw03BIJ1fv38Yty4tEsdUu3f1t3y9USY0=; b=AGH9YMd0SM1CfIOdVduPJtHrxcIp9xJGUtGcy5zRKLSS7cKU/B7v9MR5 6axodIG3ZiEeynV5tZzTenV4opCb51LYIITajZsTrx0J9n02vVe+eDCAt t3mbFUvbEMsr9Cx7DvlH/oUI+9Jbr/ws7GUD9NiWKQqqlyU4hY6+4W0yT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAL5mgVStJV2P/2dsb2JhbABZgwaBKsxbAoEYFgEBAQEBfYQCAQEBAwE4LxEBDAQLEQQBAQEJFggHCQMCAQIBNAkIBgEMAQUCAQGILgnWSgEBAQEBAQEBAQEBAQEBAQEBAQEBAReQTwcGhDABBI1Zi3+BIoMSgjuIbINigX4egVQ+MIJDAQEB X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="377788246" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 05 Dec 2014 08:08:08 +0000 Received: from [10.55.51.195] (ams-ppsenak-8712.cisco.com [10.55.51.195]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB5885nc032254; Fri, 5 Dec 2014 08:08:06 GMT Message-ID: <548167E5.5030800@cisco.com> Date: Fri, 05 Dec 2014 09:08:05 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> <547DF219.4020500@cisco.com> <547ECA2E.9030808@cisco.com> <54809DB4.4060407@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Yfx4vcQ4ODZApSVddonCw7YEws0 Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 08:08:32 -0000 Shraddha, On 12/5/14 05:52 , Shraddha Hegde wrote: > Peter, > > > > >> Would this prefix range be propagated from backbone area to non-backbone area? > > yes, SRMS range advertisements will be propagated between areas if LSA type 10 is used for the advertisement. > > You mean area scope (type 10) LSAs will be flooded across area boundary? Or you mean they will be > Re-originated at the boundary and if AS scope LSA (type 11) they will be flooded across the boundary? type 10 will be reoriginated, type 11 will be flooded across. > >> >> Keeping the prefix ranges confined within route types would make it much more simple. > > true, but it will make the deployment harder. > > OK. I see your point. > > > I think the document needs to capture the information that the prefix range can have different route-types covered. > It wasn't clear from reading the document. Probably an "elements of procedure" section is required for the prefix range TLV > To cover the flooding scope and other aspects. sure. > > One more point to be mentioned is that if there is a prefix range TLV that covers a certain prefix and there is also a prefix SID > For the same prefix , then the prefix SID should be considered and the SID in the prefix range should be ignored. agreed. Will add that to the doc. thanks, Peter > > Rgds > Shraddha > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Thursday, December 04, 2014 11:15 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, > > On 12/4/14 17:45 , Shraddha Hegde wrote: >> >> Peter, >> >>> >>>> I would think that we should have "route type" as in Extended prefix >>>> TLV instead of just having a bit indicating "inter area" >>> >>> route-type would be misleading for range, as single range can include >>> prefixes of various types (intra, inter, external). We have discussed >>> this between authors and we agreed route-type is not the right way. >>> >>> The prefix range TLV is carried in Extended prefix LSA which is based on scope of flooding. >>> If we combine intra/inter/external in the prefix range TLV, what scope is used for flooding the extended prefix LSA? >> >> prefix range is used for SR mapping server to optimize the SID >> advertisement. Prefix range as such does not need to have a route >> type, because it is not advertising a reachability. One can use domain >> wide flooding for certain external prefix, but use regular inter-area >> distribution for prefix range that is covering the external prefix. >> >> >> Combining the different route types in the prefix range TLV looks very complex. >> How practical it is in a real deployment to get a prefix range that covers through intra/inter/external route types? > > Imagine you want to advertise a SIDs for a range 192.0.2.1, Prefix Length 32, Range Size 255. Out of that range individual /32 prefixes can be of different route-types. Prefix range does not have a route-type. > > > >> >> In my opinion, it is adding unnecessary complexity into the protocol. >> If a prefix range covers intra and inter area routes would the IA flag be set? > > IA flag has nothing to do with the route-type. IA flag means that the range advertisement has bean 'leaked' between areas and is used to prevent redundant leaking. > >> Would this prefix range be propagated from backbone area to non-backbone area? > > yes, SRMS range advertisements will be propagated between areas if LSA type 10 is used for the advertisement. > >> If some prefix range contains a mix of inter and external how's the inter area prefix SIDs >> Propagated into NSSA area and external ones blocked? > > that is not a problem. You may not have external prefix in NSSA area, but the range can still cover such external prefix. In such case the SID for the external prefix will never be used in NSSA area. > > >> >> Keeping the prefix ranges confined within route types would make it much more simple. > > true, but it will make the deployment harder. > > thanks, > Peter >> >> Rgds >> Shraddha >> >> >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Wednesday, December 03, 2014 2:01 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, >> >> please see inline: >> >> On 12/3/14 06:10 , Shraddha Hegde wrote: >>> Peter, >>> >>> >>> >>>> Shouldn't each node in broadcast link originate LAN adj-SID >>>> and advertise label to all other nodes on the link? >>> >>> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency >>> to non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. >>> >>> Is there a specific reason to advertise adj-sid for the DR and LAN adj-sid for non-DR? >>> Is it because the Neighbor-ID is already part of Extended link TLV and we are saving 4 bytes? >> >> for adjacency on 2p2 link and adjacency to DR, link-type and link-id in Extended link TLV is used. For non-DR case, we need to describe the neighbor by neighbor-id, so we needed a new sub-TLV to do that. >> >>> >>> >>>> I would think that we should have "route type" as in Extended prefix >>>> TLV instead of just having a bit indicating "inter area" >>> >>> route-type would be misleading for range, as single range can include >>> prefixes of various types (intra, inter, external). We have discussed >>> this between authors and we agreed route-type is not the right way. >>> >>> The prefix range TLV is carried in Extended prefix LSA which is based on scope of flooding. >>> If we combine intra/inter/external in the prefix range TLV, what scope is used for flooding the extended prefix LSA? >> >> prefix range is used for SR mapping server to optimize the SID >> advertisement. Prefix range as such does not need to have a route >> type, because it is not advertising a reachability. One can use domain >> wide flooding for certain external prefix, but use regular inter-area >> distribution for prefix range that is covering the external prefix. >> >> thanks, >> Peter >> >>> >>> >>> Rgds >>> Shraddha >>> >>> -----Original Message----- >>> From: Peter Psenak [mailto:ppsenak@cisco.com] >>> Sent: Tuesday, December 02, 2014 10:39 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, >>> >>> please see inline: >>> >>> On 12/2/14 17:50 , Shraddha Hegde wrote: >>>> Authors, >>>> Some comments on the draft. >>>> >>>> 1. The draft refers to the various use cases in the use case document >>>> in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the >>>> section of the use case draft which is applicable for each reference >>>> instead of giving generic reference. >>> >>> sure, we can add that. >>> >>>> 2. Section 7.2 LAN Adj-sid sub TLV: >>>> >>>> Based on the description of the text it appears that the LAN AdjSID >>>> Sub TLV can contain multiple neighbor-ID /SID pairs based on the >>>> nodes attached to a broadcast network. The TLV diagram should depict >>>> carrying multiple such pairs. >>> >>> no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor. >>> If you have more non-DR neighbors, you need to advertise multiple LAN Adj-SID Sub-TLVs. >>> >>> >>>> "It is used to advertise a SID/Label for an >>>> adjacency to a non-DR node on a broadcast or NBMA network." >>>> Does the above statement mean only DR originates the LAN-Adj SIDand >>>> advertises label to non-DR nodes? >>> >>> no. >>> >>>> Shouldn't each node in broadcast link originate LAN adj-SID >>>> and advertise label to all other nodes on the link? >>> >>> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency >>> to non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN. >>> >>>> >>>> 3. Adj-Sid sub TLV section 7.1: >>>> >>>> Description of V-flag mentions Prefix-SID, it should be changed to Adj-SID. >>> >>> good catch, will correct. >>> >>>> >>>> 4. Section 4: Extended prefix range TLV is very similar to Extended >>>> prefix TLV just that it has additional range associated with it. >>> >>> yes, that is correct. >>> >>>> >>>> I would think that we should have "route type" as in Extended prefix >>>> TLV instead of just having a bit indicating "inter area" >>> >>> route-type would be misleading for range, as single range can include >>> prefixes of various types (intra, inter, external). We have discussed >>> this between authors and we agreed route-type is not the right way. >>> >>> thanks, >>> Peter >>> >>>> Rgds >>>> Shraddha >>> >>> . >>> >> >> . >> > > . > From nobody Mon Dec 8 11:04:58 2014 Return-Path: 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 63A641ACD75 for ; Mon, 8 Dec 2014 11:04:56 -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 O9784wEvZo6z for ; Mon, 8 Dec 2014 11:04:55 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66B81ACD88 for ; Mon, 8 Dec 2014 11:04:54 -0800 (PST) Received: from [216.82.253.163] by server-17.bemta-7.messagelabs.com id 50/37-02679-656F5845; Mon, 08 Dec 2014 19:04:54 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-4.tower-166.messagelabs.com!1418065494!24733590!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6872 invoked from network); 8 Dec 2014 19:04:54 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-4.tower-166.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2014 19:04:54 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id E76092A12D; Mon, 8 Dec 2014 19:04:53 +0000 (GMT) Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT01.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 12:04:53 -0700 From: "Osborne, Eric" To: "Acee Lindem (acee)" , OSPF WG List Thread-Topic: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" Thread-Index: AQHQDpNXZI6jJnSBTkWiIGV9XoGXjpyGFnuA Date: Mon, 8 Dec 2014 19:04:52 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD010F4F78@USIDCWVEMBX08.corp.global.level3.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.206] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/gLZIZfVX6JRXVoWxUaszZj0BLrg Subject: Re: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:04:56 -0000 Support. eric > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee) > Sent: Tuesday, December 02, 2014 7:52 PM > To: OSPF WG List > Subject: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF > Protocol" >=20 > We=B9ve been working on this for several IETFs now and the chairs believe= it > is time for WG adoption. Note that this document started in the NETMOD WG= . > Please indicate your support of opposition of WG adoptions. Here is a URL > for your convenience: >=20 > http://www.ietf.org/id/draft-yeung-netmod-ospf-02.txt >=20 > Thanks, > Acee and Abhay >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Tue Dec 9 10:06:11 2014 Return-Path: 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 337561A8AC4 for ; Tue, 9 Dec 2014 10:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 NrgKaKFJDKOG for ; Tue, 9 Dec 2014 10:05:59 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A701A8AC5 for ; Tue, 9 Dec 2014 10:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=624; q=dns/txt; s=iport; t=1418148359; x=1419357959; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sGR14NjUWC6jf3wqiXHi0KcpkwIhdyBbiVEiIzm7je8=; b=G46nppJGUrFEKjCZ8YXfLPmulfkeCTQx35Iwq6UyG86CLFShxC1ipZZF buTnK7Svh6Z/QsAwG+lMZtS5q5jAZ51e8zCP3VhBvq5jHvY7jel9I68MI TqDdeYBA4n7xWPzUQdW2ut3mSJPh/Sf7jCw4B3H/+y19YQaN/X8NYlSe1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcHAM45h1StJA2I/2dsb2JhbABZgwZSWASDAcMehgkCHIEKFgEBAQEBfYQDAQEENFUCAQgcKAICMCUCBBMJiC8No0CcXgaXFgEBAQEBBQEBAQEBHYEgjyOCaYFNBY4NiRWBDYJfiiCDXoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="379180421" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 09 Dec 2014 18:05:34 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB9I5Y20014096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Dec 2014 18:05:34 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 12:05:34 -0600 From: "Acee Lindem (acee)" To: OSPF WG List Thread-Topic: OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" Thread-Index: AQHQDpNXZI6jJnSBTkWiIGV9XoGXjpyHqQ+A Date: Tue, 9 Dec 2014 18:05:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="euc-kr" Content-ID: <85D2FD6B7DFD264C92A44D7266E050CC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/IbDIxUefaDdfYH-JoVlN2-9E9W4 Subject: Re: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:06:06 -0000 U3BlYWtpbmcgYXMgV0cgbWVtYmVyOiBTdXBwb3J0DQoNCk9uIDEyLzIvMTQsIDc6NTEgUE0sICJB Y2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5XZan2dmUgYmVl biB3b3JraW5nIG9uIHRoaXMgZm9yIHNldmVyYWwgSUVURnMgbm93IGFuZCB0aGUgY2hhaXJzIGJl bGlldmUgaXQNCj5pcyB0aW1lIGZvciBXRyBhZG9wdGlvbi4gTm90ZSB0aGF0IHRoaXMgZG9jdW1l bnQgc3RhcnRlZCBpbiB0aGUgTkVUTU9EIFdHLg0KPlBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBv cnQgb2Ygb3Bwb3NpdGlvbiBvZiBXRyBhZG9wdGlvbnMuIEhlcmUgaXMgYSBVUkwNCj5mb3IgeW91 ciBjb252ZW5pZW5jZToNCj4NCj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXlldW5nLW5l dG1vZC1vc3BmLTAyLnR4dA0KPg0KPlRoYW5rcywNCj5BY2VlIGFuZCBBYmhheQ0KPiANCj4NCg0K From nobody Tue Dec 9 17:57:51 2014 Return-Path: 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 E26EF1A8785 for ; Tue, 9 Dec 2014 17:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 InAdtuuit40I for ; Tue, 9 Dec 2014 17:57:46 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475641A876F for ; Tue, 9 Dec 2014 17:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=771; q=dns/txt; s=iport; t=1418176666; x=1419386266; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+qyzfpFB+z8AWWNnzhwZ/bnkx1/oF1aBB8AxATEJMik=; b=Ltwyy1mzYfO2mdZYD1ZucrXcIiEJviWBkfnRCUoKGjLxBAusbrVf4E1r /gtihkeBgPxOldqnW2ENteLLpuWXPbzLzKMmGoOF2iMjQJWLgixExhmde enXns4L6m6R+ct9WqRUHALu5XaRB+w9o5EDRQwrMxOkwWdccoH207jPuC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFADuoh1StJV2Z/2dsb2JhbABZgmQiUlgExiEKhgkCgSgWAQEBAQF9hAIBAQEEAQEBaxcEAgEIEQQBAQsdBycLFAkIAgQBEggBiC8BDNc1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF49SOAaDG4EVBYkXgxeBWoobgl2KFoNegjCBPm8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,549,1413244800"; d="scan'208";a="375837628" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 10 Dec 2014 01:57:45 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBA1vjG4005875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Dec 2014 01:57:45 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 19:57:45 -0600 From: "Les Ginsberg (ginsberg)" To: "Acee Lindem (acee)" , OSPF WG List Thread-Topic: OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) Thread-Index: AQHQDpQUQKQv9qcPok6eEYXmUp8Sy5yIHC8Q Date: Wed, 10 Dec 2014 01:57:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0CFBq5XemZn4a_gLuc1hc0R9PlI Subject: Re: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 01:57:48 -0000 Support. Les -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Tuesday, December 02, 2014 4:57 PM To: OSPF WG List Subject: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Prot= ocol" (resent in plan text mode) We=B9ve been working on this for several IETFs now and the chairs believe i= t is time for WG adoption. Note that this document started in the NETMOD WG= . Please indicate your support of opposition of WG adoptions. Here is a URL f= or your convenience: http://www.ietf.org/id/draft-yeung-netmod-ospf-02.txt Thanks, Acee and Abhay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From nobody Wed Dec 10 12:54:14 2014 Return-Path: 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 28B3B1A0065 for ; Wed, 10 Dec 2014 12:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 mxBfePrEeLW4 for ; Wed, 10 Dec 2014 12:54:10 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAB51A0018 for ; Wed, 10 Dec 2014 12:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=780; q=dns/txt; s=iport; t=1418244851; x=1419454451; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=P8KmoJ99qjFvOvqr4jagD9S7++xqlzWiccnP1q0tBdo=; b=H1eOtCHjmMuWmbXpGGnAQzc+uVuEGRRBQ7RnNNLdJvbHM9530O35+5tm dm1ZRxCY8j/+A7eExwI740YhHBeoIshVk7Kq595gj0K9nCUFHhcC00Fz6 IJvSD6iv/+OXsbiMattQlqusXCJPflqDVprSeLPX1RDWaBVpCcNyRvBWY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgIAASyiFStJV2Y/2dsb2JhbABZgwZSWASDAcBSGIIbCoVuHoECFgEBAQEBfYQNAQEEAQEBMTodAQgcHwkEJQsnBAESCYgvDaQanF4Gl0QBAQEHAQEBAQEdgSCOMIMjgU0FjgKIcYEMglyKE4NfgjCBPm4BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="379292609" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 10 Dec 2014 20:54:10 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBAKs9xt027762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Dec 2014 20:54:09 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.83]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 14:54:09 -0600 From: "Derek Man-Kit Yeung (myeung)" To: "Acee Lindem (acee)" , OSPF WG List Thread-Topic: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) Thread-Index: AQHQFLtx5iXIuo2ODkaRfD28fdO9oA== Date: Wed, 10 Dec 2014 20:54:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.154.209.46] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ywsSqW903wVG6m5EKuinxdKokSE Subject: Re: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 20:54:12 -0000 U3VwcG9ydC4NCi0gRGVyZWsNCg0KT24gMTIvMi8xNCA0OjU3IFBNLCAiQWNlZSBMaW5kZW0gKGFj ZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KDQo+V2Wp9nZlIGJlZW4gd29ya2luZyBvbiB0 aGlzIGZvciBzZXZlcmFsIElFVEZzIG5vdyBhbmQgdGhlIGNoYWlycyBiZWxpZXZlIGl0DQo+aXMg dGltZSBmb3IgV0cgYWRvcHRpb24uIE5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IHN0YXJ0ZWQgaW4g dGhlIE5FVE1PRCBXRy4NCj5QbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9mIG9wcG9zaXRp b24gb2YgV0cgYWRvcHRpb25zLiBIZXJlIGlzIGEgVVJMDQo+Zm9yIHlvdXIgY29udmVuaWVuY2U6 DQo+DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC15ZXVuZy1uZXRtb2Qtb3NwZi0wMi50 eHQNCj4NCj5UaGFua3MsDQo+QWNlZSBhbmQgQWJoYXkNCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk9TUEYgbWFpbGluZyBsaXN0DQo+T1NQRkBp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3NwZg0KDQo= From nobody Wed Dec 10 13:34:13 2014 Return-Path: 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 4F7251A01CB for ; Wed, 10 Dec 2014 13:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ISfjSW_s3oZy for ; Wed, 10 Dec 2014 13:33:58 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578491A8795 for ; Wed, 10 Dec 2014 13:33:51 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-08-54885fa98ef7 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D7.CD.25146.9AF58845; Wed, 10 Dec 2014 15:58:49 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:33:48 -0500 From: Jeff Tantsura To: "Acee Lindem (acee)" , OSPF WG List Thread-Topic: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) Thread-Index: AQHQFLtx5iXIuo2ODkaRfD28fdO9oJyJJksA Date: Wed, 10 Dec 2014 21:33:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPuO7K+I4Qgz8vZC0mv53HbNFy7x67 A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx6alWQQNHxbufh5kaGJ+wdzFyckgImEh0 vl/DBmGLSVy4tx7I5uIQEjjCKPFk2yoWCGc5o8TN4//BOtgEDCT+fzvOAmKLCLhLzFp5mBnE FhYolDh8Yx0zRLxI4sntZ+wQtpHEhqnzwGwWAVWJtqMTgGwODl4Bc4nJcytBwkICuhL//n1h ArE5BfQk1m4+AjaGEeig76fWgMWZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xgtiiQL3PNmyG ekxJ4uPv+ewQvVoSX37sY4OwrSV2dd+CmqkoMaX7IVgNr4CgxMmZT1gmMIrPQrJuFpL2WUja ZyFpn4WkfQEj6ypGjtLi1LLcdCPDTYzAmDomwea4g3HBJ8tDjAIcjEo8vB/q2kOEWBPLiitz DzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAoKJFxRlhUu8D5sv2iLDNp 9+WaAaufh8Yobtlj/m3vdJMM3ruTYnO5C18KnVgVuEWnn/v2zh33ZjktfjNJrllEOKihdM6B z1O+VS52ubPes9/FVdfLQ2a28++5U/peuDhnLu5QnLMqfmL3CdGm6xU7YpKn9PpPEf2YNjmi +Avzt6cz6h4/N/ioxFKckWioxVxUnAgA0HkkQ4oCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/RW2L7BGc0svk3b7E0Pmt3uAfWyY Subject: Re: [OSPF] OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" (resent in plan text mode) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 21:34:06 -0000 WWVzL3N1cHBvcnQNCg0KQ2hlZXJzLA0KSmVmZg0KDQoNCg0KDQo+DQo+T24gMTIvMi8xNCA0OjU3 IFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5X Zan2dmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgZm9yIHNldmVyYWwgSUVURnMgbm93IGFuZCB0aGUg Y2hhaXJzIGJlbGlldmUNCj4+aXQNCj4+aXMgdGltZSBmb3IgV0cgYWRvcHRpb24uIE5vdGUgdGhh dCB0aGlzIGRvY3VtZW50IHN0YXJ0ZWQgaW4gdGhlIE5FVE1PRA0KPj5XRy4NCj4+UGxlYXNlIGlu ZGljYXRlIHlvdXIgc3VwcG9ydCBvZiBvcHBvc2l0aW9uIG9mIFdHIGFkb3B0aW9ucy4gSGVyZSBp cyBhIFVSTA0KPj5mb3IgeW91ciBjb252ZW5pZW5jZToNCj4+DQo+Pmh0dHA6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQteWV1bmctbmV0bW9kLW9zcGYtMDIudHh0DQo+Pg0KPj5UaGFua3MsDQo+PkFj ZWUgYW5kIEFiaGF5DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj5PU1BGIG1haWxpbmcgbGlzdA0KPj5PU1BGQGlldGYub3JnDQo+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3NwZg0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+T1NQRiBtYWlsaW5nIGxpc3QNCj5P U1BGQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3Bm DQoNCg== From nobody Wed Dec 10 14:18:35 2014 Return-Path: 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 B10A11A9105 for ; Wed, 10 Dec 2014 14:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 kYG1y2hCTcOg for ; Wed, 10 Dec 2014 14:18:31 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6818D1A90E2 for ; Wed, 10 Dec 2014 14:18:31 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAMIT3Z017820; Wed, 10 Dec 2014 22:18:29 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAMISOQ017809 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 22:18:29 GMT From: "Adrian Farrel" To: Date: Wed, 10 Dec 2014 22:18:23 -0000 Message-ID: <016b01d014c7$36781070$a3683150$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAUxy/xv4A6WSFHTVGGS+yMvOIUNg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21166.002 X-TM-AS-Result: No--8.213-10.0-31-10 X-imss-scan-details: No--8.213-10.0-31-10 X-TMASE-MatchedRID: IxP3l+4FnGunykMun0J1wpmug812qIbzGSqdEmeD/nWJ1jCZ8wjy4JR+ kRMH4E2jBt5KNd+dhyrEB8MHlGe36p83k0Mo0lWmypeMiaCPnxvo/OjYPAGsigzvg1/q1MH2Ud7 jq59x7R0dUFxPoCZVxzkzhYN4xIABHY/bzRmIaZGRGzV8Bxg0cSvY8ODAxZsiDjir5qnzSYR3/S CdaWuuB6yllYROb8WGGKhF5tSv7ONtNLAj8DYO8MfjT/BPakB39XLIIJw3zCqvloAnGr4qhicR0 4SgDltlKDkw2HqkkkeUxA5IDaSRMmKplHd7ThK1HcQQBuf4ZFt9LQinZ4QefL6qvLNjDYTwfY9h sM0xN70qtq5d3cxkNU6pw6bcLY29frUddGLsegWhzJ7mP/+F8d1HTX7ee+38h28Tu3uUtuXAvpL E+mvX8g== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/lBphGWfTRBfEUlYppOOsPqK9GuY Cc: ospf@ietf.org Subject: [OSPF] AD review of draft-ietf-ospf-te-metric-extensions X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 22:18:33 -0000 Authors, Thanks for your work on this document. I am acting as "responsible" AD as Alia (the usual AD for OSPF) is a co-author. I've done my usual review on receiving the publication request. I see a few small issues to attend to, but these do not need to hold up the IETF last call. I will start that last call and submit my comments as last call comments that you can handle along with any other comments you receive. Thanks, Adrian === Please look for places where you have "proposed" something and change that to "defined". --- It would be good to include a reference for encoding floating point integers. The usual is (I think)... IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8). --- Section 4.2.5 Implementations MAY also permit the configuration of a static (non dynamic) offset value (in microseconds) to be added to the measured delay value, to facilitate the communication of operator specific delay constraints. On the third reading I got it! I'm slow (I have a high delay :-) The point here is that the measured value and the static value are added together and the sum is transmitted in this field. I'd suggest... Implementations MAY also permit the configuration of a static (non dynamic) offset value (in microseconds) to be added to the measured delay value before encoding into this TLV, to facilitate the communication of operator specific delay constraints. Similarly in 4.2.6. --- 4.2.7 appears out of sequence. But since it repeats the content of 4.2.4 I suggest you merge them and talk about the plurality of fields. --- Section 7 "Sections 6 and 7 provide" should be 5 and 6. --- Section 10 "As per (RFC3630), unrecognized TLVs should be silently ignored" There has been confusion about what 3630 means by "silently ignored". In particular, some enthusiastic implementations thought this meant the TLVs should be stripped from the LSA before it is propagated. I think it is worth the few words to explicitly state that this is not the case. --- Section 13 RFC 4203 is used in a normative way, please move it to the other section. From nobody Wed Dec 10 15:03:11 2014 Return-Path: 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 9216C1A1A9E; Wed, 10 Dec 2014 15:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dCpe6Ar25a-l; Wed, 10 Dec 2014 15:03:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E81D21A1A91; Wed, 10 Dec 2014 15:03:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141210230306.25645.76164.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 15:03:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/HhxzV8DvJlWF7FI5jVsiHbI2DkE Cc: ospf@ietf.org Subject: [OSPF] Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 23:03:09 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPF Traffic Engineering (TE) Metric Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics. This document describes extensions to RFC 3630 'Traffic Engineering (TE) Extensions to OSPF Version 2' such that network performance information can be distributed and collected in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2442/ http://datatracker.ietf.org/ipr/2199/ From nobody Wed Dec 10 15:07:26 2014 Return-Path: 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 92CB81A1AB6; Wed, 10 Dec 2014 15:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 qY04OJYicWlM; Wed, 10 Dec 2014 15:07:17 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37351A1A99; Wed, 10 Dec 2014 15:07:16 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAN7Ea8027624; Wed, 10 Dec 2014 23:07:14 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAN7DLQ027612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 23:07:14 GMT From: "Adrian Farrel" To: Date: Wed, 10 Dec 2014 23:07:08 -0000 Message-ID: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAUzgRtbjhNr7FGTP+6Nt7S5T90Cg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21168.000 X-TM-AS-Result: No--10.997-10.0-31-10 X-imss-scan-details: No--10.997-10.0-31-10 X-TMASE-MatchedRID: hls5oAVArl8zx9GDMr0HvzYTypjB3iDVuikHZcC6ceATVJPv0YKEKViN xVLlNmEJqfCLrIKbnQdeB/1Ewo8I25SL8e/MGApZvHKClHGjjr3MmaoHJ8BpLRjQD3m2MCf7nCV oYY7P13c/OKf/TcIu01Go54/BITPFjl2kmBb+Ta8a9NdQGl95NtSqEluSYtV7CqIJhrrDy29HZG kGAQcl8zOeKJ9f2YhH9jZuJ+IsfxALe4e10OySpeLdprnA5EQRhQaFqMRElgk5yqWxi+AoVa0Ro mhWPJaQZkLhmTuGQ/W0Bgm0CXGm5o9oUcx9VMLgOX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAq rjYtFiTv2VzAWQ7VszqymjNMJTnLvannU3YcsfNsR/KkA6+ocn7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/edeDHoRK3Vt5KJciT4HCUZbDxf8 Cc: ospf@ietf.org, ietf@ietf.org Subject: Re: [OSPF] Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 23:07:21 -0000 All, I reviewed this document as AD and found a few small points that I have asked the authors to address as IETF last call comments. Adrian === Please look for places where you have "proposed" something and change that to "defined". --- It would be good to include a reference for encoding floating point integers. The usual is (I think)... IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8). --- Section 4.2.5 Implementations MAY also permit the configuration of a static (non dynamic) offset value (in microseconds) to be added to the measured delay value, to facilitate the communication of operator specific delay constraints. On the third reading I got it! I'm slow (I have a high delay :-) The point here is that the measured value and the static value are added together and the sum is transmitted in this field. I'd suggest... Implementations MAY also permit the configuration of a static (non dynamic) offset value (in microseconds) to be added to the measured delay value before encoding into this TLV, to facilitate the communication of operator specific delay constraints. Similarly in 4.2.6. --- 4.2.7 appears out of sequence. But since it repeats the content of 4.2.4 I suggest you merge them and talk about the plurality of fields. --- Section 7 "Sections 6 and 7 provide" should be 5 and 6. --- Section 10 "As per (RFC3630), unrecognized TLVs should be silently ignored" There has been confusion about what 3630 means by "silently ignored". In particular, some enthusiastic implementations thought this meant the TLVs should be stripped from the LSA before it is propagated. I think it is worth the few words to explicitly state that this is not the case. --- Section 13 RFC 4203 is used in a normative way, please move it to the other section. From nobody Sat Dec 13 10:19:55 2014 Return-Path: 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 1F94B1A1AC8 for ; Sat, 13 Dec 2014 10:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 yLMD52TWdLUP for ; Sat, 13 Dec 2014 10:19:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84D11A1A78 for ; Sat, 13 Dec 2014 10:19:51 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1384.namprd05.prod.outlook.com (25.160.107.142) with Microsoft SMTP Server (TLS) id 15.1.36.22; Sat, 13 Dec 2014 18:19:28 +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; Sat, 13 Dec 2014 18:19:28 +0000 From: Shraddha Hegde To: "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAW/kuWGscufT8EQDeA0Yv5U29aiw== Date: Sat, 13 Dec 2014 18:19:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1384; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1384; x-forefront-prvs: 04244E0DC5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(54206007)(40100003)(54606007)(77156002)(62966003)(74316001)(33656002)(19625215002)(92566001)(101416001)(2656002)(86362001)(19300405004)(16236675004)(122556002)(46102003)(87936001)(54356999)(50986999)(99396003)(19580395003)(4396001)(21056001)(120916001)(64706001)(20776003)(99286002)(66066001)(110136001)(230783001)(106356001)(105586002)(76576001)(97736003)(229853001)(107046002)(15975445007)(2351001)(68736005)(31966008)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1384; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1381D2E0190364379D1752B1D5610BY1PR0501MB1381_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2014 18:19:28.3761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1384 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/aUcFeWMlVMyNbR9Y5D_mSBLTjpk Cc: OSPF WG List Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 18:19:54 -0000 --_000_BY1PR0501MB1381D2E0190364379D1752B1D5610BY1PR0501MB1381_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, When there are multiple parallel links between two nodes, it is use= ful to Group them into different bundles and use each bundle for load-balancing f= or 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 o= ne 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 --_000_BY1PR0501MB1381D2E0190364379D1752B1D5610BY1PR0501MB1381_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 

        When ther= e are multiple parallel links between two nodes, it is useful to=

Group them into different bundles and use each bundl= e for load-balancing  for different traffic flows.

 

What we have in adjacency sid is just a flag to indi= cate that the label is a “set label” by setting a flag

In adj-sid TLV. It serves the purpose when all the p= arallel 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-i= d” is needed to associate the label with the interface group.

 

Any thoughts on this?

 

Rgds

Shraddha

 

 

--_000_BY1PR0501MB1381D2E0190364379D1752B1D5610BY1PR0501MB1381_-- From nobody Sun Dec 14 02:38:03 2014 Return-Path: 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 8F8F71A6F32 for ; Sun, 14 Dec 2014 02:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 awjthJ_IsDlU for ; Sun, 14 Dec 2014 02:38:00 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9BA1A6F30 for ; Sun, 14 Dec 2014 02:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=901; q=dns/txt; s=iport; t=1418553479; x=1419763079; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pE00Lc8pVQRLp74RSTWgOE2oEd6LLB2NsVWEERQVG2U=; b=i4T1reWJWfyPIPmlTXeW33hN/W+14fKhYnb+G2eE5TCXxhQ9BKnYgS97 UbRHtU5YVtpf6ZA4W4q9QQUmSVa5WpfjiJqCgufBy+CiC4cv1rg1uZ/a1 mQ8G7CfGrCaAkj8uUklFGrL8POk1J0TjPrTz+PDbO9GOts4sWwE16yzMf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAGpnjVStJssW/2dsb2JhbABazS6CTQKBJwEBAQEBfYQNAQEEMgEFQAEQCxgJFg8JAwIBAgFFBgEMAQcBAYgo0GEBAQEBAQEBAQEBAQEBAQEBAQEBARiPcgeEKQEElnGFeYs+IoNtPYJzAQEB X-IronPort-AV: E=Sophos;i="5.07,574,1413244800"; d="scan'208";a="274000073" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Dec 2014 10:37:57 +0000 Received: from [10.55.51.197] (ams-ppsenak-8714.cisco.com [10.55.51.197]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBEAbv1E029776; Sun, 14 Dec 2014 10:37:57 GMT Message-ID: <548D6885.1060001@cisco.com> Date: Sun, 14 Dec 2014 11:37:57 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/FHOlyZWORrwHuQLndz93wovvtKw Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 10:38:01 -0000 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 > From nobody Tue Dec 16 08:34:36 2014 Return-Path: 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 78D3E1A1BE1 for ; Tue, 16 Dec 2014 08:34: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 qbjDL1IIblAX for ; Tue, 16 Dec 2014 08:34:33 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4C8D1A1BD9 for ; Tue, 16 Dec 2014 08:34:33 -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.31.17; Tue, 16 Dec 2014 16:34:32 +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 16:34:32 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAW/kuWGscufT8EQDeA0Yv5U29aiwAi7qSAAGZ5RmA= Date: Tue, 16 Dec 2014 16:34:32 +0000 Message-ID: References: <548D6885.1060001@cisco.com> In-Reply-To: <548D6885.1060001@cisco.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:BY1PR0501MB1381; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1381; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(189002)(199003)(24454002)(13464003)(479174004)(87936001)(74316001)(40100003)(21056001)(86362001)(54356999)(50986999)(120916001)(105586002)(33656002)(101416001)(99396003)(122556002)(92566001)(62966003)(31966008)(2950100001)(54606007)(2900100001)(77156002)(2656002)(19580395003)(19580405001)(106356001)(76176999)(20776003)(64706001)(54206007)(107046002)(230783001)(4396001)(97736003)(66066001)(99286002)(76576001)(46102003)(102836002)(68736005); 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; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/MYAttCqFwy5HwPAaNpUQiYwKmdA Cc: OSPF WG List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:34:35 -0000 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 neighbor= s, 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]=20 Sent: Sunday, December 14, 2014 4:08 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg 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 wa= y 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=20 > 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=20 > label is a "set label" by setting a flag > > In adj-sid TLV. It serves the purpose when all the parallel links are=20 > 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=20 > associate the label with the interface group. > > Any thoughts on this? > > Rgds > > Shraddha > From nobody Tue Dec 16 09:31:37 2014 Return-Path: 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 ; 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 ; 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 ; 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 To: "rob.shakir@bt.com" , "ppsenak@cisco.com" , "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: References: In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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]=20 Sent: Tuesday, December 16, 2014 10:11 PM To: Shraddha Hegde; ppsenak@cisco.com; draft-ietf-ospf-segment-routing-exte= nsions@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? 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 rou= ter. The Extended link LSA contains the adj-sid Label TLV which Has the "s bit" set indicating the label is a se= t label. If there are multiple such set labels associated with a link, its = difficult to associate which label was allocated for which bundle. =20 If there is a some kind of identifier for the bun= dle, the label can be easily associated. It is surely the local configuration of the node that determines what the b= undle is in the first place, and this is persistent over a graceful-restart= of the session? Yes, IMO local configuration decides which links belong to the b= undle. This configuration is persistent over graceful restart. You MAY want to bundle all the parallel links bet= ween two nodes into a bundle, in which case the existing protocol operation= s 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. =20 Thanks, r. [16/12/2014 16:34, "Shraddha Hegde" ] >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=20 >neighbors, A handle is required to associate the set label with the=20 >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.=20 >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=20 >> 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=20 >> label is a "set label" by setting a flag >> >> In adj-sid TLV. It serves the purpose when all the parallel links =20 >> 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=20 >> associate the label with the interface group. >> >> Any thoughts on this? >> >> Rgds >> >> Shraddha >> > From nobody Tue Dec 16 10:06:23 2014 Return-Path: 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 E09391A802D for ; Tue, 16 Dec 2014 10:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 GmbZQy-CNSkB for ; Tue, 16 Dec 2014 10:06:15 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9EA1A802A for ; Tue, 16 Dec 2014 10:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1418753173; x=1419962773; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+GHvK85BsFeF6CYggKjz0fqIa1j7tYnbjzpXYfWdiTA=; b=VetwdwfDftacGJKt7zKiD7+fElaPPhhoafhjranlrAiarm2+EwkgVeqs +J+UNu29wQXUfNfjP/1T+s6nI9OBpzg9d0S+ZowVIsgpvyMj5KzMcLRrd MMrIosiZMZ6VF2V0hwmmliD0uNL4LQi90GfjaF7Tr+iwWKgbnoa0vMhWH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEACR0kFStJssW/2dsb2JhbABahDDLawKBMAEBAQEBfYQMAQEBAwE4NQsBDAQLEQQBAQEJFggHCQMCAQIBNAkIBgEMAQUCAQGIIAjVMQEBAQEBAQEBAQEBAQEBAQEBAQEBARePcgcGhCMBBJZxgQuCXoIQi0Aig209MIJDAQEB X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="272416902" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Dec 2014 18:06:11 +0000 Received: from [10.55.51.195] (ams-ppsenak-8712.cisco.com [10.55.51.195]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBGI6B4P004393; Tue, 16 Dec 2014 18:06:11 GMT Message-ID: <54907493.8030800@cisco.com> Date: Tue, 16 Dec 2014 19:06:11 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "rob.shakir@bt.com" , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/nyd1t3ndpKr9DKGVrIE7Xrwna0g Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:06:20 -0000 Hi Shraddha, please see inline: On 12/16/14 18:31 , Shraddha Hegde wrote: > 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? > > 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. I don't think adding additional info to be distributed by the protocol is the right way to address the local data persistence across restart/switch over. If you need to make sure that the LSA contains the same data prior and after GR, you can checkpoint them and restore from checkpoint after GR. > > > 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? > > 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. sure. If you need to make sure that same label is used prior and post GR, you do not need protocol help for that. thanks, Peter > > > Thanks, > r. > > [16/12/2014 16:34, "Shraddha Hegde" ] > >> 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 >>> >> > > . > From nobody Tue Dec 16 21:44:06 2014 Return-Path: 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 894361A1BFA for ; Tue, 16 Dec 2014 21:44:05 -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, 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 PVCQh-to0JMo for ; Tue, 16 Dec 2014 21:44:03 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA871A1BFC for ; Tue, 16 Dec 2014 21:44:02 -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.31.17; Wed, 17 Dec 2014 05:43:38 +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; Wed, 17 Dec 2014 05:43:38 +0000 From: Shraddha Hegde To: Peter Psenak , "rob.shakir@bt.com" , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAW/kuWGscufT8EQDeA0Yv5U29aiwAi7qSAAGZ5RmAACscGgAABGydwAAHhR4AAF+92MA== Date: Wed, 17 Dec 2014 05:43:38 +0000 Message-ID: References: <54907493.8030800@cisco.com> In-Reply-To: <54907493.8030800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1381; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1381; x-forefront-prvs: 042857DBB5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(13464003)(51704005)(164054003)(377454003)(189002)(199003)(107046002)(93886004)(230783001)(4396001)(54206007)(2501002)(64706001)(46102003)(68736005)(102836002)(66066001)(99286002)(76576001)(97736003)(86362001)(101416001)(33656002)(122556002)(99396003)(50986999)(54356999)(105586002)(120916001)(87936001)(21056001)(40100003)(74316001)(2201001)(20776003)(76176999)(31966008)(62966003)(92566001)(2656002)(77156002)(106356001)(2900100001)(19580405001)(2950100001)(54606007)(19580395003); 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; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/zKhglxxt-SRqzUqjWSFNvbpXhgk Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 05:44:05 -0000 Peter, Please see inline: -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Tuesday, December 16, 2014 11:36 PM To: Shraddha Hegde; rob.shakir@bt.com; draft-ietf-ospf-segment-routing-exte= nsions@tools.ietf.org Cc: ospf@ietf.org Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 Hi Shraddha, please see inline: On 12/16/14 18:31 , Shraddha Hegde wrote: > 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;=20 > 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? > > The graceful restart in OSPF as per RFC 3623 works by learni= ng the LSAs from neighbor after the restating router comes up and builds t= he LSA database based on the learnt LSAs. > The neighbor relays back the LSA generated by the restarting r= outer. 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, i= ts 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. I don't think adding additional info to be distributed by the protocol is t= he right way to address the local data persistence across restart/switch ov= er. If you need to make sure that the LSA contains the same data prior and = after GR, you can checkpoint them and restore from checkpoint after GR. I think if the protocol extensions are flexible enough, no checkp= ointing would be required and everything can be recovered from the informat= ion learnt from neighbor. It is not only about "graceful restart", I find th= e information to associate set label to a bundle missing. Think of an appli= cation which has to look up the LSA database and build An explicitly routed label stack using bundled lab= els. If there are multiple adj-sid with "s bit set"originated by a node, i= t's not easy to make a choice which set label to use! Since there is no information about which label cor= responds to which bundle. I find the adj-sid set a very interesting and ver= y useful feature but find the OSPF/ISIS protocol extensions not flexible en= ough to accommodate all the different ways An operator may want to deploy bundles. =20 > > 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-resta= rt of the session? > > 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 operat= ions work fine. > But I think protocol should provide flexibili= ty to make multiple bundles, able to assign a link to multiple bundles (if = so desired) and recovering the label across restart. sure. If you need to make sure that same label is used prior and post GR, y= ou do not need protocol help for that. thanks, Peter > > > Thanks, > r. > > [16/12/2014 16:34, "Shraddha Hegde" ] > >> Peter, >> >> An extended link LSA can contain multiple adj-sid labels with "s bit" se= t. >> During graceful restart , when self generated LSAs are learnt from=20 >> neighbors, A handle is required to associate the set label with the=20 >> 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,=20 >>> it is useful to >>> >>> Group them into different bundles and use each bundle for load-balancin= g >>> for different traffic flows. >>> >>> What we have in adjacency sid is just a flag to indicate that the=20 >>> label is a "set label" by setting a flag >>> >>> In adj-sid TLV. It serves the purpose when all the parallel links=20 >>> 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=20 >>> associate the label with the interface group. >>> >>> Any thoughts on this? >>> >>> Rgds >>> >>> Shraddha >>> >> > > . > From nobody Tue Dec 16 23:52:58 2014 Return-Path: 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 1580D1A0673; Tue, 16 Dec 2014 23:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.011 X-Spam-Level: X-Spam-Status: No, score=-12.011 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_BOTCC=2.5, USER_IN_DEF_DKIM_WL=-7.5] 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 QpYbnedlFWOx; Tue, 16 Dec 2014 23:52:52 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7292B1A6F49; Tue, 16 Dec 2014 23:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6020; q=dns/txt; s=iport; t=1418802771; x=1420012371; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VfQvrRV3fiarnZKd2E9EI8gVGm1iGFBt+CNNrP8jdTs=; b=aUlnAtCmwvnjnHHZDRhcLfcJYtZE8Bm+VNYK8Erg9bs7JkIO9ZEd++Mm FNcQgXo4uyddqYqq1pwm6yQUZYhgG4U9HUEM7KEofDPqbkPmyq9D34Ayl aYnYK3Z1rZXMd0q78PPYZlMQiquPsiUfdYYdGxGWM+5FEv0II6ENP+UIS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEA1kVStJssW/2dsb2JhbABahDDLdwKBMQEBAQEBfYQMAQEBAwE4NQsBDAQLEQQBAQEJFggHCQMCAQIBNAkIBgEMAQUCAQGIIAjUKQEBAQEBAQEBAQEBAQEBAQEBAQEBARePcgcGhCMBBJZ3gQuCXoIQi0Aig209MIJDAQEB X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208";a="273243763" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 17 Dec 2014 07:52:49 +0000 Received: from [10.55.51.195] (ams-ppsenak-8712.cisco.com [10.55.51.195]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBH7qmiK007650; Wed, 17 Dec 2014 07:52:49 GMT Message-ID: <54913651.2050600@cisco.com> Date: Wed, 17 Dec 2014 08:52:49 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "rob.shakir@bt.com" , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: <54907493.8030800@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/3gc_buKlG12KxURi8CKQY9jvWXE Cc: "ospf@ietf.org" , "isis-wg@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 07:52:54 -0000 Shraddha, added ISIS WG alias, as this is not specific to OSPF. Please see inline: On 12/17/14 06:43 , Shraddha Hegde wrote: > Peter, > > > Please see inline: > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Tuesday, December 16, 2014 11:36 PM > To: Shraddha Hegde; rob.shakir@bt.com; draft-ietf-ospf-segment-routing-extensions@tools.ietf.org > Cc: ospf@ietf.org > Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 > > Hi Shraddha, > > please see inline: > > On 12/16/14 18:31 , Shraddha Hegde wrote: >> 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? >> >> 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. > > I don't think adding additional info to be distributed by the protocol is the right way to address the local data persistence across restart/switch over. If you need to make sure that the LSA contains the same data prior and after GR, you can checkpoint them and restore from checkpoint after GR. > > I think if the protocol extensions are flexible enough, no checkpointing would be required and everything can be recovered from the information learnt from neighbor. > > It is not only about "graceful restart", I find the information to associate set label to a bundle missing. Think of an application which has to look up the LSA database and build > An explicitly routed label stack using bundled labels. If there are multiple adj-sid with "s bit set"originated by a node, it's not easy to make a choice which set label to use! > Since there is no information about which label corresponds to which bundle. Let's imagine you have 4 links (l1, l2, l3, l4) between R1 and R2. You split these to two sets on R1: S1(l1,l2) S1(l3,l4) On R1, for links in S1 you advertise Adj-SID 10 and for link in S2 you advertise Adj-SID 20. Any router looking at advertisement from R1 can clearly see the two sets. Am I missing something? thanks, Peter > > I find the adj-sid set a very interesting and very useful feature but find the OSPF/ISIS protocol extensions not flexible enough to accommodate all the different ways > An operator may want to deploy bundles. > > >> >> 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? >> >> 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. > > sure. If you need to make sure that same label is used prior and post GR, you do not need protocol help for that. > > thanks, > Peter >> >> >> Thanks, >> r. >> >> [16/12/2014 16:34, "Shraddha Hegde" ] >> >>> 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 >>>> >>> >> >> . >> > > . > From nobody Wed Dec 17 00:51:49 2014 Return-Path: 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 920761A1B9A; Wed, 17 Dec 2014 00:51:48 -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, 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 qZsFD1UCEay5; Wed, 17 Dec 2014 00:51:46 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B711A1B88; Wed, 17 Dec 2014 00:51:45 -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; Wed, 17 Dec 2014 08:51:22 +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; Wed, 17 Dec 2014 08:51:22 +0000 From: Shraddha Hegde To: Peter Psenak , "rob.shakir@bt.com" , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAW/kuWGscufT8EQDeA0Yv5U29aiwAi7qSAAGZ5RmAACscGgAABGydwAAHhR4AAF+92MAAE7zeAAAFQ+jA= Date: Wed, 17 Dec 2014 08:51:21 +0000 Message-ID: References: <54907493.8030800@cisco.com> <54913651.2050600@cisco.com> In-Reply-To: <54913651.2050600@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; 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: 042857DBB5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(199003)(24454002)(164054003)(51704005)(479174004)(189002)(2656002)(87936001)(76576001)(46102003)(21056001)(66066001)(64706001)(20776003)(33656002)(31966008)(54206007)(4396001)(101416001)(19580405001)(19580395003)(2900100001)(2950100001)(102836002)(68736005)(106356001)(99286002)(105586002)(93886004)(230783001)(107046002)(97736003)(2501002)(40100003)(92566001)(122556002)(86362001)(2201001)(62966003)(77156002)(54606007)(50986999)(76176999)(54356999)(74316001)(99396003)(120916001); 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: 17 Dec 2014 08:51:21.1753 (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/qY98xh4gUSOG58lbTMHpelyaOCw Cc: "ospf@ietf.org" , "isis-wg@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 08:51:48 -0000 -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Wednesday, December 17, 2014 1:23 PM To: Shraddha Hegde; rob.shakir@bt.com; draft-ietf-ospf-segment-routing-exte= nsions@tools.ietf.org Cc: ospf@ietf.org; isis-wg@ietf.org Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 Shraddha, added ISIS WG alias, as this is not specific to OSPF. Please see inline: On 12/17/14 06:43 , Shraddha Hegde wrote: > Peter, > > > Please see inline: > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Tuesday, December 16, 2014 11:36 PM > To: Shraddha Hegde; rob.shakir@bt.com;=20 > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org > Cc: ospf@ietf.org > Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 > > Hi Shraddha, > > please see inline: > > On 12/16/14 18:31 , Shraddha Hegde wrote: >> 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;=20 >> 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? >> >> The graceful restart in OSPF as per RFC 3623 works by learn= ing 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 th= e bundle, the label can be easily associated. > > I don't think adding additional info to be distributed by the protocol is= the right way to address the local data persistence across restart/switch = over. If you need to make sure that the LSA contains the same data prior an= d after GR, you can checkpoint them and restore from checkpoint after GR. > > I think if the protocol extensions are flexible enough, no chec= kpointing would be required and everything can be recovered from the inform= ation learnt from neighbor. > > It is not only about "graceful restart", I find= the information to associate set label to a bundle missing. Think of an ap= plication which has to look up the LSA database and build > An explicitly routed label stack using bundled = labels. If there are multiple adj-sid with "s bit set"originated by a node= , it's not easy to make a choice which set label to use! > Since there is no information about which label = corresponds to which bundle. Let's imagine you have 4 links (l1, l2, l3, l4) between R1 and R2. You spli= t these to two sets on R1: S1(l1,l2) S1(l3,l4) On R1, for links in S1 you advertise Adj-SID 10 and for link in S2 you adve= rtise Adj-SID 20. Any router looking at advertisement from R1 can clearly see the two sets. A= m I missing something? Lets say set S1 has some characteristic "X" and set S2 has cha= racteristic "Y". Lets say we want to build explicit routed label st= ack which says " give me load balancing path using links with characteristi= c X". =20 Lets say there is another set of nodes R3 and R4 a= nd similar S1 and S2 bundles on them and R3 advertising label 30 and 40 for= S1 and S2 Respectively. Labels are local to the nodes and we = cannot use labels to identify what characteristic or set they stand for. .To satisfy the constraint whether to use label 10 Or 20 on R1 and whether to use 30 or 40 is a proble= m. The application which is trying to build the label stack cannot identify= which label to use from R1 and R3 because there are sets and = labels but which label Represents which set is missing. If there is an identifier for the set and this iden= tifier comes with label it can be done easily. =20 =20 thanks, Peter > > I find the adj-sid set a very interesting and = very useful feature but find the OSPF/ISIS protocol extensions not flexible= enough to accommodate all the different ways > An operator may want to deploy bundles. > > >> >> It is surely the local configuration of the node that determines what th= e bundle is in the first place, and this is persistent over a graceful-rest= art of the session? >> >> Yes, IMO local configuration decides which links belong to th= e bundle. This configuration is persistent over graceful restart. >> You MAY want to bundle all the parallel link= s between two nodes into a bundle, in which case the existing protocol oper= ations work fine. >> But I think protocol should provide flexibi= lity to make multiple bundles, able to assign a link to multiple bundles (i= f so desired) and recovering the label across restart. > > sure. If you need to make sure that same label is used prior and post GR,= you do not need protocol help for that. > > thanks, > Peter >> >> >> Thanks, >> r. >> >> [16/12/2014 16:34, "Shraddha Hegde" ] >> >>> Peter, >>> >>> An extended link LSA can contain multiple adj-sid labels with "s bit" s= et. >>> During graceful restart , when self generated LSAs are learnt from=20 >>> neighbors, A handle is required to associate the set label with the=20 >>> 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=20 >>>> nodes, it is useful to >>>> >>>> Group them into different bundles and use each bundle for load-balanci= ng >>>> for different traffic flows. >>>> >>>> What we have in adjacency sid is just a flag to indicate that the=20 >>>> label is a "set label" by setting a flag >>>> >>>> In adj-sid TLV. It serves the purpose when all the parallel links=20 >>>> 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=20 >>>> associate the label with the interface group. >>>> >>>> Any thoughts on this? >>>> >>>> Rgds >>>> >>>> Shraddha >>>> >>> >> >> . >> > > . > From nobody Wed Dec 17 02:17:01 2014 Return-Path: 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 D05FE1A887E; Wed, 17 Dec 2014 02:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 XlwxAUR9Objv; Wed, 17 Dec 2014 02:16:55 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA4A1A701C; Wed, 17 Dec 2014 02:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1432; q=dns/txt; s=iport; t=1418811415; x=1420021015; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qKCmb231B1e1RwYdrPDufYC9UNct+jXNfJM8pBpbFi0=; b=LOauVm/3JWPWKku3Ed8XQ5wcvAecKStXR9Pn1Sv73J71xaYsVOjQnL75 Ui4mF3tZkG0Ob7z5aWjaJDpBMVenvVDCWI0GU3bysnhkoEgT2REtOQBGE e5qSPRGgwHSuGiLJohPFfG+8GO6U/Tkg2nLQTzH/hZPmyvs8cNbvC+p5V o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAPtWkVStJssW/2dsb2JhbABQCs1Kgk0CgTMBAQEBAX2EDQEBBDg6BgEQCxgJFg8JAwIBAgFFBgEMAQcBAYgo1BsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxZcB4QpAQSWeIV8i0Qig209gnQBAQE X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="273310890" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 17 Dec 2014 10:16:53 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBHAGrX5010092; Wed, 17 Dec 2014 10:16:53 GMT Message-ID: <54915815.2050102@cisco.com> Date: Wed, 17 Dec 2014 11:16:53 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "rob.shakir@bt.com" , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" References: <54907493.8030800@cisco.com> <54913651.2050600@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/g8mIKQwsP-Uh3v8SD-2I9rCV6ho Cc: "ospf@ietf.org" , "isis-wg@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 10:16:57 -0000 Shraddha, On 12/17/14 09:51 , Shraddha Hegde wrote: > Lets say set S1 has some characteristic "X" and set S2 has characteristic "Y". > Lets say we want to build explicit routed label stack which says " give me load balancing path using links with characteristic X". > > Lets say there is another set of nodes R3 and R4 and similar S1 and S2 bundles on them and R3 advertising label 30 and 40 for S1 and S2 > Respectively. Labels are local to the nodes and we cannot use labels to identify what characteristic or set they stand for. > > To satisfy the constraint whether to use label 10 > Or 20 on R1 and whether to use 30 or 40 is a problem. The application which is trying to build the label stack cannot identify which label to use from R1 and R3 because there are sets and labels but which label Represents which set is missing. > If there is an identifier for the set and this identifier comes with label it can be done easily. If I understand you correctly, what you want to color links based on the link characteristics - e.g. you want to associate link with a group (color) and group (color) to have global significance. Sure, you can do that, but I do not see a direct relationship to SR, e.g. I would not add the group-id to the Adj-SID sub-TLV. You can define a new sub-TLV for the group-id distribution and advertise it in the Extended link TLV. thanks, Peter From nobody Wed Dec 17 21:08:35 2014 Return-Path: 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 41BA21A01AA; Wed, 17 Dec 2014 21:08:33 -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, 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 llpNGCM0wBEM; Wed, 17 Dec 2014 21:08:30 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765FC1A01A9; Wed, 17 Dec 2014 21:08:30 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1382.namprd05.prod.outlook.com (25.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.36.22; Thu, 18 Dec 2014 05:08:07 +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; Thu, 18 Dec 2014 05:08:06 +0000 From: Shraddha Hegde To: Peter Psenak , "rob.shakir@bt.com" , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" Thread-Topic: draft-ietf-ospf-segment-routing-extensions-03 Thread-Index: AdAW/kuWGscufT8EQDeA0Yv5U29aiwAi7qSAAGZ5RmAACscGgAABGydwAAHhR4AAF+92MAAE7zeAAAFQ+jAAA7cVgAAne0cA Date: Thu, 18 Dec 2014 05:08:06 +0000 Message-ID: References: <54907493.8030800@cisco.com> <54913651.2050600@cisco.com> <54915815.2050102@cisco.com> In-Reply-To: <54915815.2050102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.17] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1382; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(189002)(51704005)(377454003)(199003)(13464003)(230783001)(76576001)(99286002)(101416001)(120916001)(2950100001)(107046002)(105586002)(106356001)(2501002)(97736003)(46102003)(31966008)(102836002)(2900100001)(68736005)(33656002)(99396003)(50986999)(122556002)(92566001)(77156002)(86362001)(54356999)(76176999)(2201001)(19580395003)(62966003)(54606007)(21056001)(40100003)(93886004)(64706001)(20776003)(66066001)(87936001)(54206007)(4396001)(19580405001)(2656002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1382; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A: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: 18 Dec 2014 05:08:06.7340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/QXBCF16FIJxT2nixB4IKdfDG078 Cc: "ospf@ietf.org" , "isis-wg@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 05:08:33 -0000 OK. Sounds good. Rgds Shraddha -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Wednesday, December 17, 2014 3:47 PM To: Shraddha Hegde; rob.shakir@bt.com; draft-ietf-ospf-segment-routing-exte= nsions@tools.ietf.org Cc: ospf@ietf.org; isis-wg@ietf.org Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 Shraddha, On 12/17/14 09:51 , Shraddha Hegde wrote: > Lets say set S1 has some characteristic "X" and set S2 has c= haracteristic "Y". > Lets say we want to build explicit routed label stack which says " give = me load balancing path using links with characteristic X". > > Lets say there is another set of nodes R3 and R4 and similar S1 and S2=20 > bundles on them and R3 advertising label 30 and 40 for S1 and S2 Respecti= vely. Labels are local to the nodes and we cannot use labels to identify wh= at characteristic or set they stand for. > > To satisfy the constraint whether to use label 10 > Or 20 on R1 and whether to use 30 or 40 is a problem. The application whi= ch is trying to build the label stack cannot identify which label to use fr= om R1 and R3 because there are sets and labels but which label= Represents which set is missing. > If there is an identifier for the set and this identifier comes with labe= l it can be done easily. If I understand you correctly, what you want to color links based on the li= nk characteristics - e.g. you want to associate link with a group (color) and group (color) to have global significance. Sure, you can do that, but I do not see a direct relationship to SR, e.g. I= would not add the group-id to the Adj-SID sub-TLV. You can define a new su= b-TLV for the group-id distribution and advertise it in the Extended link T= LV. thanks, Peter From nobody Wed Dec 24 00:09:54 2014 Return-Path: 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 331311ACD7F; Wed, 24 Dec 2014 00:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 WpxtjEaZcpea; Wed, 24 Dec 2014 00:09:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADCC1ACE57; Wed, 24 Dec 2014 00:09:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, ospf@ietf.org, ospf-chairs@tools.ietf.org, draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org, acee@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141224080928.21137.15747.idtracker@ietfa.amsl.com> Date: Wed, 24 Dec 2014 00:09:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/xmMpYgx3ObL-76-ZfhxnJYxucM0 Cc: iesg-secretary@ietf.org Subject: [OSPF] Last Call Expired: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 08:09:33 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Wed Dec 24 02:58:14 2014 Return-Path: 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 13A001AD02F; Wed, 24 Dec 2014 02:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4FFGC_S2LrJr; Wed, 24 Dec 2014 02:58:11 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F01B1AD02C; Wed, 24 Dec 2014 02:57:53 -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; Wed, 24 Dec 2014 10:57:52 +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; Wed, 24 Dec 2014 10:57:51 +0000 From: Shraddha Hegde To: "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" Thread-Topic: Mail regarding draft-ietf-ospf-segment-routing-extensions Thread-Index: AdAfZ+2t8gRxJR1gRJOVEF41ljB4rw== Date: Wed, 24 Dec 2014 10:57:51 +0000 Message-ID: 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-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1381; x-forefront-prvs: 04359FAD81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(74316001)(19580395003)(107046002)(4396001)(229853001)(66066001)(230783001)(99396003)(86362001)(120916001)(76576001)(54206007)(46102003)(77156002)(62966003)(97736003)(92566001)(33656002)(101416001)(54356999)(106356001)(54606007)(68736005)(50986999)(102836002)(87936001)(2656002)(99286002)(31966008)(21056001)(122556002)(20776003)(64706001)(105586002)(40100003)(15975445007)(2900100001); 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: multipart/alternative; boundary="_000_BY1PR0501MB13819883015276791F20D631D5540BY1PR0501MB1381_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2014 10:57:51.5061 (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/Oi7-9CBZJY4C1XOKZufn9fzGCU8 Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [OSPF] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 10:58:12 -0000 --_000_BY1PR0501MB13819883015276791F20D631D5540BY1PR0501MB1381_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, We have a "backup flag" in adjacency sid to indicate whether the label is p= rotected 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 --_000_BY1PR0501MB13819883015276791F20D631D5540BY1PR0501MB1381_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors,
 
 
We have a “backup flag” in adjacency sid to indicate wheth= er the label is protected or not.
Similarly. I think we need a flag in prefix-sid as well to indicate wh= ether the node-sid is to be protected or not.
 
Any thoughts on this?
 
Rgds
Shraddha
 
 --_000_BY1PR0501MB13819883015276791F20D631D5540BY1PR0501MB1381_-- From nobody Mon Dec 29 00:06:05 2014 Return-Path: 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 DBA591A000C; Mon, 29 Dec 2014 00:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 fGRrcTgwRqLh; Mon, 29 Dec 2014 00:05:26 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8572E1A000F; Mon, 29 Dec 2014 00:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=647; q=dns/txt; s=iport; t=1419840325; x=1421049925; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=r8bHNaQ0xvqZ63sUaUd4jUbh2fibHZP2eOzeKwGF9mA=; b=iFM8aS6mG1Kt/Wi2EpTtB796Aqpoa2voi2BroVy7hTnMe3ELPDIYei4P 3BN1mSrqc2pPFgpFMSJB15icXJ6qlVtrcaO7WGKhRzrbLzeE0Ez8TszP4 e2K44JlBLI8PVnhD0pNkxi7uKz1mvQzHoPwE0eyyHSy9pWaL4B8fEBYBS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEAM0KoVStJssW/2dsb2JhbABcg1hYxmYKhXMCgSEBAQEBAX2EDQEBBAEBAS8BBTYKARALGAkWDwkDAgECARUwBgEMAQUCAQGIKA3EewEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjwwaAQFPB4QpAQSXCIYEi0wig289MYEMgTcBAQE X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="286614479" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 Dec 2014 08:05:10 +0000 Received: from [10.61.76.181] (ams3-vpn-dhcp3253.cisco.com [10.61.76.181]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBT8599b026342; Mon, 29 Dec 2014 08:05:09 GMT Message-ID: <54A10B35.4030301@cisco.com> Date: Mon, 29 Dec 2014 09:05:09 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/HKhawpx4evxuTsiBPs28-NlkMmA Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 08:05:40 -0000 X-List-Received-Date: Mon, 29 Dec 2014 08:05:40 -0000 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 > From nobody Mon Dec 29 00:15:40 2014 Return-Path: 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 2CBED1A0010; Mon, 29 Dec 2014 00:15: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, 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 RlMK8dXbu5vJ; Mon, 29 Dec 2014 00:15:33 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18ADD1A000F; Mon, 29 Dec 2014 00:15:32 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1382.namprd05.prod.outlook.com (25.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 08:15:10 +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 08:15:10 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-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+2t8gRxJR1gRJOVEF41ljB4rwD1jwiAAAAaeDA= Date: Mon, 29 Dec 2014 08:15:09 +0000 Message-ID: References: <54A10B35.4030301@cisco.com> In-Reply-To: <54A10B35.4030301@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:BY1PR0501MB1382; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1382; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(199003)(189002)(377454003)(51704005)(13464003)(24454002)(86362001)(97736003)(101416001)(50986999)(2656002)(99396003)(54606007)(62966003)(76576001)(230783001)(74316001)(120916001)(4396001)(21056001)(122556002)(2201001)(19580395003)(54356999)(76176999)(54206007)(87936001)(92566001)(77156002)(46102003)(2950100001)(106356001)(99286002)(68736005)(20776003)(64706001)(33656002)(31966008)(2900100001)(15975445007)(19580405001)(107046002)(66066001)(102836002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1382; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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 08:15:09.8567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/VA_ZvWE1nuL5aONiGhbKCFeOhek Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 08:15:35 -0000 Peter, If there is a service which has to use un-protected path and while building= such a path if the node-sids=20 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.=20 Prefix -sids could also be used to represent different service endpoints wh= ich makes it even more relevant to have=20 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]=20 Sent: Monday, December 29, 2014 1:35 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg; 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-exten= sions Shraddha, node-SID is advertised by the router for the prefix that is directly attach= ed 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=20 > is protected or not. > Similarly. I think we need a flag in prefix-sid as well to indicate=20 > 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 > From nobody Mon Dec 29 00:19:14 2014 Return-Path: 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 084331A0011; Mon, 29 Dec 2014 00:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 zk8mmS3bEpqJ; Mon, 29 Dec 2014 00:19:08 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34481A001B; Mon, 29 Dec 2014 00:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1859; q=dns/txt; s=iport; t=1419841148; x=1421050748; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZywmLXPhoLbEXtUVCRDS9oYPUaviqCyH82nzBvCLno0=; b=L3XOx7hGAyZHuEtGiJIcnwBYo2Tc3ySRCmqexlvjQjhZoFPbHh3zCC9H NsXqbhq+P5dB4UlXeU+K/mnfJ5ZouJQhn75+fkjAJEaAWzBULUkgnDJpd e5XkISXaB8cW4BvtX0bX7eHnwUSqqvBurWD5ixBR//4w60pXD4Wg4333c I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEEAFgNoVStJssW/2dsb2JhbABcg1hYxmYKhXMCgSEBAQEBAX2EDAEBAQQBAQE1NgoBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYBDAEFAgEBiCgNxQQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8MGgEBTwcGhCMBBJcIhgSLTCKDbz0xgQyBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="291422575" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 29 Dec 2014 08:19:06 +0000 Received: from [10.61.76.181] (ams3-vpn-dhcp3253.cisco.com [10.61.76.181]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBT8J4N8025385; Mon, 29 Dec 2014 08:19:05 GMT Message-ID: <54A10E78.6030006@cisco.com> Date: Mon, 29 Dec 2014 09:19:04 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" References: <54A10B35.4030301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0TNUwtG6jPeZn45ar0bqRM8o27s Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 08:19:13 -0000 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 >> > > . > From nobody Mon Dec 29 00:26:45 2014 Return-Path: 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 B26081A0013; Mon, 29 Dec 2014 00:26:42 -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, 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 tKyAh_WmukMs; Mon, 29 Dec 2014 00:26:39 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB911A0007; Mon, 29 Dec 2014 00:26:39 -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.49.12; Mon, 29 Dec 2014 08:26:16 +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 08:26:15 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-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+2t8gRxJR1gRJOVEF41ljB4rwD1jwiAAAAaeDAAAGH0AAAABIpw Date: Mon, 29 Dec 2014 08:26:15 +0000 Message-ID: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> In-Reply-To: <54A10E78.6030006@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:BY1PR0501MB1383; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(479174004)(24454002)(51704005)(13464003)(2900100001)(31966008)(54206007)(74316001)(2950100001)(2201001)(107046002)(102836002)(15975445007)(120916001)(33656002)(68736005)(86362001)(54606007)(92566001)(97736003)(62966003)(77156002)(50986999)(122556002)(21056001)(64706001)(46102003)(66066001)(99396003)(101416001)(40100003)(93886004)(54356999)(76176999)(4396001)(106356001)(99286002)(2656002)(230783001)(76576001)(20776003)(87936001)(19580395003)(19580405001); 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; 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 08:26:15.9173 (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/iF169gQ2UN2_oXI2WfOTHwRBbMs Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 08:26:42 -0000 Yes.You are right. Lets say a prefix sid has a flag "p flag". If this is on it means build a p= ath 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 f= lag. 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]=20 Sent: Monday, December 29, 2014 1:49 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg; 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-exten= sions Shraddha, the problem is that the node that is advertising the node-sid can not adver= tise any data regarding the protection of such prefix, because the prefix i= s 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=20 > building such a path if the node-sids Need to be used (one reason=20 > 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=20 > endpoints which makes it even more relevant to have A means of representi= ng 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;=20 > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;=20 > draft-ietf-isis-segment-routing-extensions@tools.ietf.org > Cc: ospf@ietf.org; isis-wg@ietf.org > Subject: Re: [Isis-wg] Mail regarding=20 > draft-ietf-ospf-segment-routing-extensions > > Shraddha, > > node-SID is advertised by the router for the prefix that is directly atta= ched 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=20 >> label is protected or not. >> Similarly. I think we need a flag in prefix-sid as well to indicate=20 >> 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 >> > > . > From nobody Mon Dec 29 00:32:30 2014 Return-Path: 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 20A871A0121; Mon, 29 Dec 2014 00:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 uGf5qgZIYzz9; Mon, 29 Dec 2014 00:32:26 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03891A0037; Mon, 29 Dec 2014 00:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3087; q=dns/txt; s=iport; t=1419841932; x=1421051532; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rgJMQ1JTr3Lhv8HTv8H3pPz+5Ps0u9cs6LJknMMM4qE=; b=PlsHp7bzBubp8LuiY9XaXgiqwqBIz9csDD3oyl4aG+DooDpmZUEqxUSp 3h4YWSC8U4yuOXNfjmfCT1JESC0jtC0sgliM+TszmaqEhZpaonEH3q2mc PvuD04Q1y8RjjBk0y+9GCY0YhGTKrQzZT06JR01PWy+k3+Bwf34xMq7FH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEEALAQoVStJssW/2dsb2JhbABcg1hYxmQKhXMCgSEBAQEBAX2EDAEBAQQBAQE1NgoBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYBDAEFAgEBiCgNxQsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8MGgEBTwcGhCMBBJcIhgSLTCKDbz0xgQyBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="286639509" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 Dec 2014 08:32:10 +0000 Received: from [10.61.76.181] (ams3-vpn-dhcp3253.cisco.com [10.61.76.181]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBT8W8LG017848; Mon, 29 Dec 2014 08:32:09 GMT Message-ID: <54A11188.8040301@cisco.com> Date: Mon, 29 Dec 2014 09:32:08 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/c-K6cjnoxA8-_W6V3SC-1v2krSM Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 08:32:28 -0000 Shraddha, I do not see how an originator can set any flag regarding the protection of the locally attached prefix. It's all the routers on the path towards such prefix that need to deal with the protection. Signaling anything from the originator seems useless. 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 >>> >> >> . >> > > . > From nobody Mon Dec 29 00:47:47 2014 Return-Path: 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 B65AC1A0045; Mon, 29 Dec 2014 00:47:43 -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, 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 mQ002VO3aGKk; Mon, 29 Dec 2014 00:47:41 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25691A0039; Mon, 29 Dec 2014 00:47:40 -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 08:47:18 +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 08:47:18 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-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+2t8gRxJR1gRJOVEF41ljB4rwD1jwiAAAAaeDAAAGH0AAAABIpwAABwSQAAABH9IA== Date: Mon, 29 Dec 2014 08:47:17 +0000 Message-ID: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> In-Reply-To: <54A11188.8040301@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)(479174004)(377454003)(24454002)(199003)(13464003)(51704005)(189002)(64706001)(99286002)(66066001)(230783001)(50986999)(76176999)(102836002)(68736005)(93886004)(2201001)(2656002)(87936001)(2900100001)(21056001)(2950100001)(122556002)(20776003)(33656002)(101416001)(31966008)(40100003)(15975445007)(54606007)(107046002)(86362001)(4396001)(74316001)(19580395003)(92566001)(62966003)(97736003)(54356999)(54206007)(99396003)(106356001)(46102003)(76576001)(19580405001)(120916001)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1381; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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 08:47:17.2556 (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/nMn_9Z9wY_7MqA7dMHzAl7pcUv8 Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 08:47:43 -0000 Peter, Pls see inline. Rgds Shraddha -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Monday, December 29, 2014 2:02 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg; 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-exten= sions Shraddha, I do not see how an originator can set any flag regarding the protection of= the locally attached prefix. The originator advertises 2 node-sids. One with p flag set and t= he other without the p-flag set. =20 It's all the routers on the path towards such prefix that need to deal wit= h the protection.=20 The receiving nodes will download protected path for the node-si= d with p-flag set and download=20 Unprotected path for the node-sid with p-flag unset. Signaling anything from the originator seems useless. 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 i= s 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 advertis= ing 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 fl= ag 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;=20 > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;=20 > draft-ietf-isis-segment-routing-extensions@tools.ietf.org > Cc: ospf@ietf.org; isis-wg@ietf.org > Subject: Re: [Isis-wg] Mail regarding=20 > draft-ietf-ospf-segment-routing-extensions > > Shraddha, > > the problem is that the node that is advertising the node-sid can not adv= ertise 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=20 >> building such a path if the node-sids Need to be used (one reason=20 >> could be label stack compression) , then there has to be unprotected nod= e-sid that this service can make use of. >> >> Prefix -sids could also be used to represent different service=20 >> endpoints which makes it even more relevant to have A means of represent= ing 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=20 >> draft-ietf-ospf-segment-routing-extensions >> >> Shraddha, >> >> node-SID is advertised by the router for the prefix that is directly att= ached 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=20 >>> label is protected or not. >>> Similarly. I think we need a flag in prefix-sid as well to indicate=20 >>> 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 >>> >> >> . >> > > . > From nobody Mon Dec 29 00:56:40 2014 Return-Path: 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 D913D1A0041; Mon, 29 Dec 2014 00:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 EXkS-eobpFRM; Mon, 29 Dec 2014 00:56:34 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3851A0040; Mon, 29 Dec 2014 00:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5018; q=dns/txt; s=iport; t=1419843393; x=1421052993; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1KDv1D4mgiL9fvHeNGND6BX06z20o1aZgudykXDi3Ng=; b=cNqbk6XRt4IE3Oesh0RafeReFccMSLBmPUtSoUXnDG+yB+t/O/3mk56r 7LtQ5DzlKHlXIdQPJVMApvSUSXzywT2TJS9LKwSE0H1f0zQ1Pi/6zZMvy YuVWK3DLqxVV6/bFpLpnVkva7fOMWEBdw8hN7clcVGkrXJP9dD3PYjgBG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEEALQWoVStJssW/2dsb2JhbABcg1hYxmQKhXMCgSEBAQEBAX2EDAEBAQMBAQEBNTYKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGAQwBBQIBAYggCA3FDAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjwwaAQFKBQcGhCMBBJcIhgSLTCKDbz0xgQyBNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="286661942" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 Dec 2014 08:56:30 +0000 Received: from [10.61.76.181] (ams3-vpn-dhcp3253.cisco.com [10.61.76.181]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBT8uT2u006533; Mon, 29 Dec 2014 08:56:30 GMT Message-ID: <54A1173D.6000200@cisco.com> Date: Mon, 29 Dec 2014 09:56:29 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/xR_xc1a0VkahT14lkzvlfY2hylU Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 08:56:37 -0000 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. > 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. > 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. > 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 >>>> >>> >>> . >>> >> >> . >> > > . > From nobody Mon Dec 29 01:06:15 2014 Return-Path: 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 To: Peter Psenak , "draft-ietf-ospf-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: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 n= ot want to divert the traffic on protected path in any case. So when the originator of node-sid signals un-protected path requirement, t= here 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 f= lag which can be set for the unprotected path.=20 By default it remains off and gives the behavior as it exists today. Rgds Shraddha -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Monday, December 29, 2014 2:26 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg; 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-exten= sions 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 cer= tain 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 a= s 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;=20 > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;=20 > draft-ietf-isis-segment-routing-extensions@tools.ietf.org > Cc: ospf@ietf.org; isis-wg@ietf.org > Subject: Re: [Isis-wg] Mail regarding=20 > 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. > 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. > The receiving nodes will download protected path for the=20 > node-sid with p-flag set and download Unprotected path for the node-sid w= ith p-flag unset. > > Signaling anything from the originator seems useless. > For node-sids it's the others who need to build the forwardin= g plane but it's only the originator who can signal which of > Sid need to be built with protection and which n= ot. 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=20 > advertising multiple adj-sids one with B-flag on and other with b-flag of= f , 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 thi= s flag. >> >> The applications building the paths will either use prefix-sids with p f= lag 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=20 >> draft-ietf-ospf-segment-routing-extensions >> >> Shraddha, >> >> the problem is that the node that is advertising the node-sid can not ad= vertise any data regarding the protection of such prefix, because the prefi= x 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=20 >>> building such a path if the node-sids Need to be used (one reason=20 >>> could be label stack compression) , then there has to be unprotected no= de-sid that this service can make use of. >>> >>> Prefix -sids could also be used to represent different service=20 >>> endpoints which makes it even more relevant to have A means of represen= ting 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=20 >>> draft-ietf-ospf-segment-routing-extensions >>> >>> Shraddha, >>> >>> node-SID is advertised by the router for the prefix that is directly at= tached 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=20 >>>> label is protected or not. >>>> Similarly. I think we need a flag in prefix-sid as well to indicate=20 >>>> 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 >>>> >>> >>> . >>> >> >> . >> > > . > From nobody Mon Dec 29 01:08:28 2014 Return-Path: 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 6A5991A0058; Mon, 29 Dec 2014 01:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6aLrrpdf154W; Mon, 29 Dec 2014 01:08:12 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A754E1A0006; Mon, 29 Dec 2014 01:08:11 -0800 (PST) Received: from [86.180.124.183] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Y5WIy-0000Ff-T0; Mon, 29 Dec 2014 09:08:00 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=utf-8 From: Rob Shakir In-Reply-To: <54A1173D.6000200@cisco.com> Date: Mon, 29 Dec 2014 09:07:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8673017E-4E86-4D2E-8522-DF49ED869E2D@rob.sh> References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> To: Peter Psenak , Shraddha Hegde X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/c85N1SeVNlCu4vEuz4XBGY8pYd4 Cc: "ospf@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 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 09:08:26 -0000 Peter, Shraddha, Primarily =E2=80=94 I don=E2=80=99t think that use of the =E2=80=98B=E2=80= =99 flag in the Adj-SID implies that there MUST be a backup route = installed, it merely indicates that the Adj-SID MAY be subject to = re-routing (and hence strict placement on an adjacency may not be = honoured during link failures). For me, I=E2=80=99m unclear on what the practical use of not requesting = backup for a {Node,Prefix}-SID could be =E2=80=94 its very nature = (=E2=80=9Cthe shortest path to X=E2=80=9D where X is a node/prefix) = means that it is not well defined in terms of a route through the = network, and hence is not well defined in terms of performance. This (to = me) says that we cannot really rely on such a SID for = performance-sensitive traffic, and hence must always be able to tolerate = events such as FRR paths during protection. The fact that AdjSID maps deterministically to a particular link, about = which the calculating entity (PCE/iLER) can know details of, means that = performance can be inferred - and hence strict affinity to that path = (and/or failure when it is not available) is of utility. Kind regards, r. > On 29 Dec 2014, at 08:56, Peter Psenak wrote: >=20 > Shraddha, >=20 > 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? >=20 > 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. >=20 > thanks, > Peter >=20 >=20 > On 12/29/14 09:47 , Shraddha Hegde wrote: >> Peter, >>=20 >>=20 >> Pls see inline. >>=20 >> Rgds >> Shraddha >>=20 >> -----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 >>=20 >> Shraddha, >>=20 >> I do not see how an originator can set any flag regarding the = protection of the locally attached prefix. >> The originator advertises 2 node-sids. One with p flag set = and the other without the p-flag set. >>=20 >> It's all the routers on the path towards such prefix that need to = deal with the protection. >> 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. >>=20 >> Signaling anything from the originator seems useless. >> 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. >=20 >=20 >=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> thanks, >> Peter >>=20 >> On 12/29/14 09:26 , Shraddha Hegde wrote: >>> Yes.You are right. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>>=20 >>> -----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 >>>=20 >>> Shraddha, >>>=20 >>> 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. >>>=20 >>> thanks, >>> Peter >>>=20 >>> On 12/29/14 09:15 , Shraddha Hegde wrote: >>>> Peter, >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Would be good to hear from others on this, especially operators. >>>>=20 >>>> Rgds >>>> Shraddha >>>>=20 >>>>=20 >>>> -----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 >>>>=20 >>>> Shraddha, >>>>=20 >>>> 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. >>>>=20 >>>> thanks, >>>> Peter >>>>=20 >>>> 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 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>=20 >>>>=20 >>>> . >>>>=20 >>>=20 >>> . >>>=20 >>=20 >> . >>=20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Mon Dec 29 01:33:39 2014 Return-Path: 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 E2EF51A004C; Mon, 29 Dec 2014 01:33:34 -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 VOtz62ypI1U6; Mon, 29 Dec 2014 01:33:32 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7731A0046; Mon, 29 Dec 2014 01:33:32 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1384.namprd05.prod.outlook.com (25.160.107.142) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 09:33:31 +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:33:30 +0000 From: Shraddha Hegde To: Rob Shakir , Peter Psenak Thread-Topic: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions Thread-Index: AdAfZ+2t8gRxJR1gRJOVEF41ljB4rwD1jwiAAAAaeDAAAGH0AAAABIpwAABwSQAAABH9IAAAx7iAAABm0oAAADteMA== Date: Mon, 29 Dec 2014 09:33:29 +0000 Message-ID: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> <8673017E-4E86-4D2E-8522-DF49ED869E2D@rob.sh> In-Reply-To: <8673017E-4E86-4D2E-8522-DF49ED869E2D@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1384; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1384; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(71364002)(51704005)(479174004)(189002)(377454003)(13464003)(50986999)(54356999)(46102003)(33656002)(21056001)(122556002)(97736003)(54206007)(4396001)(54606007)(76176999)(77156002)(62966003)(40100003)(19580405001)(93886004)(76576001)(92566001)(230783001)(101416001)(74316001)(15975445007)(19580395003)(66066001)(99396003)(120916001)(86362001)(31966008)(2656002)(102836002)(2900100001)(64706001)(68736005)(20776003)(99286002)(106356001)(107046002)(87936001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1384; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 09:33:29.7813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1384 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/72jVzzA5uxwuwvNqlG6J7aaQ-ps Cc: "ospf@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 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 09:33:35 -0000 Um9iLA0KDQpQbHMgc2VlIGlubGluZS4uDQoNClJnZHMNClNocmFkZGhhDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2IgU2hha2lyIFttYWlsdG86cmpzQHJvYi5zaF0gDQpT ZW50OiBNb25kYXksIERlY2VtYmVyIDI5LCAyMDE0IDI6MzggUE0NClRvOiBQZXRlciBQc2VuYWs7 IFNocmFkZGhhIEhlZ2RlDQpDYzogZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRl bnNpb25zQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4 dGVuc2lvbnNAdG9vbHMuaWV0Zi5vcmc7IG9zcGZAaWV0Zi5vcmc7IGlzaXMtd2dAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbSXNpcy13Z10gTWFpbCByZWdhcmRpbmcgZHJhZnQtaWV0Zi1vc3BmLXNl Z21lbnQtcm91dGluZy1leHRlbnNpb25zDQoNClBldGVyLCBTaHJhZGRoYSwNCg0KUHJpbWFyaWx5 IOKAlCAgSSBkb27igJl0IHRoaW5rIHRoYXQgdXNlIG9mIHRoZSDigJhC4oCZIGZsYWcgaW4gdGhl IEFkai1TSUQgaW1wbGllcyB0aGF0IHRoZXJlIE1VU1QgYmUgYSBiYWNrdXAgcm91dGUgaW5zdGFs bGVkLCBpdCBtZXJlbHkgaW5kaWNhdGVzIHRoYXQgdGhlIEFkai1TSUQgTUFZIGJlIHN1YmplY3Qg dG8gcmUtcm91dGluZyAoYW5kIGhlbmNlIHN0cmljdCBwbGFjZW1lbnQgb24gYW4gYWRqYWNlbmN5 IG1heSBub3QgYmUgaG9ub3VyZWQgZHVyaW5nIGxpbmsgZmFpbHVyZXMpLg0KDQo8U2hyYWRkaGE+ IFllcy4gSSBhZ3JlZS4NCg0KRm9yIG1lLCBJ4oCZbSB1bmNsZWFyIG9uIHdoYXQgdGhlIHByYWN0 aWNhbCB1c2Ugb2Ygbm90IHJlcXVlc3RpbmcgYmFja3VwIGZvciBhIHtOb2RlLFByZWZpeH0tU0lE IGNvdWxkIGJlIOKAlCBpdHMgdmVyeSBuYXR1cmUgKOKAnHRoZSBzaG9ydGVzdCBwYXRoIHRvIFji gJ0gd2hlcmUgWCBpcyBhIG5vZGUvcHJlZml4KSBtZWFucyB0aGF0IGl0IGlzIG5vdCB3ZWxsIGRl ZmluZWQgaW4gdGVybXMgb2YgYSByb3V0ZSB0aHJvdWdoIHRoZSBuZXR3b3JrLCBhbmQgaGVuY2Ug aXMgbm90IHdlbGwgZGVmaW5lZCBpbiB0ZXJtcyBvZiBwZXJmb3JtYW5jZS4gVGhpcyAodG8gbWUp IHNheXMgdGhhdCB3ZSBjYW5ub3QgcmVhbGx5IHJlbHkgb24gc3VjaCBhIFNJRCBmb3IgcGVyZm9y bWFuY2Utc2Vuc2l0aXZlIHRyYWZmaWMsIGFuZCBoZW5jZSBtdXN0IGFsd2F5cyBiZSBhYmxlIHRv IHRvbGVyYXRlIGV2ZW50cyBzdWNoIGFzIEZSUiBwYXRocyBkdXJpbmcgcHJvdGVjdGlvbi4NCg0K PFNocmFkZGhhPiBJdCBpcyBsaWtlbHkgdGhhdCBzb21lIGFwcGxpY2F0aW9uIHdhbnRzIHRvIHVz ZSB0aGUgbm9kZS1zaWRzIHdoZW4gdGhlIHN0cmljdCBwYXRoIGZvciBwZXJmb3JtYW5jZSBzZW5z aXRpdmUgdHJhZmZpYyBtYXRjaGVzIHdpdGggdGhhdCBvZiB0aGUgU1BGICBmb3Igc29tZSBzZWdt ZW50cyBvciBmb3IgdGhlIGVudGlyZSBwYXRoLiANCg0KVGhlIGZhY3QgdGhhdCBBZGpTSUQgbWFw cyBkZXRlcm1pbmlzdGljYWxseSB0byBhIHBhcnRpY3VsYXIgbGluaywgYWJvdXQgd2hpY2ggdGhl IGNhbGN1bGF0aW5nIGVudGl0eSAoUENFL2lMRVIpIGNhbiBrbm93IGRldGFpbHMgb2YsIG1lYW5z IHRoYXQgcGVyZm9ybWFuY2UgY2FuIGJlIGluZmVycmVkIC0gYW5kIGhlbmNlIHN0cmljdCBhZmZp bml0eSB0byB0aGF0IHBhdGggKGFuZC9vciBmYWlsdXJlIHdoZW4gaXQgaXMgbm90IGF2YWlsYWJs ZSkgaXMgb2YgdXRpbGl0eS4NCg0KDQpLaW5kIHJlZ2FyZHMsDQpyLg0KDQoNCj4gT24gMjkgRGVj IDIwMTQsIGF0IDA4OjU2LCBQZXRlciBQc2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPiB3cm90ZToN Cj4gDQo+IFNocmFkZGhhLA0KPiANCj4gSSBkbyBub3Qgc2VlIGhvdyBhbiBvcmlnaW5hdG9yIG9m IHRoZSBub2RlLXNpZCBjYW4gbWFuZGF0ZSBhIHByb3RlY3Rpb24gZm9yIHRoZSBwcmVmaXggb24g b3RoZXIgcm91dGVycy4gV2hhdCBpZiB0aGVyZSBpcyBubyBiYWNrdXAgYXZhaWxhYmxlIG9uIGEg Y2VydGFpbiBub2RlIGFsb25nIHRoZSBwYXRoPw0KPiANCj4gVGhlIHBhcmFsbGVsIHdpdGggdGhl IEItZmxhZyBpbiBhZGotc2lkcyBpcyBub3QgcmlnaHQgLSBpbiBjYXNlIG9mIGFkai1zaWQgdGhl IG9yaWdpbmF0b3IgaGFzIHRoZSBrbm93bGVkZ2UgYWJvdXQgdGhlIGxvY2FsIGFkamFjZW5jeSBw cm90ZWN0aW9uIGFuZCBhcyBzdWNoIGNhbiBzaWduYWwgaXQgaXQgaXQncyBMU0EuDQo+IA0KPiB0 aGFua3MsDQo+IFBldGVyDQo+IA0KPiANCj4gT24gMTIvMjkvMTQgMDk6NDcgLCBTaHJhZGRoYSBI ZWdkZSB3cm90ZToNCj4+IFBldGVyLA0KPj4gDQo+PiANCj4+IFBscyBzZWUgaW5saW5lLg0KPj4g DQo+PiBSZ2RzDQo+PiBTaHJhZGRoYQ0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gRnJvbTogUGV0ZXIgUHNlbmFrIFttYWlsdG86cHBzZW5ha0BjaXNjby5jb21dDQo+PiBT ZW50OiBNb25kYXksIERlY2VtYmVyIDI5LCAyMDE0IDI6MDIgUE0NCj4+IFRvOiBTaHJhZGRoYSBI ZWdkZTsgDQo+PiBkcmFmdC1pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNAdG9v bHMuaWV0Zi5vcmc7IA0KPj4gZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNp b25zQHRvb2xzLmlldGYub3JnDQo+PiBDYzogb3NwZkBpZXRmLm9yZzsgaXNpcy13Z0BpZXRmLm9y Zw0KPj4gU3ViamVjdDogUmU6IFtJc2lzLXdnXSBNYWlsIHJlZ2FyZGluZyANCj4+IGRyYWZ0LWll dGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucw0KPj4gDQo+PiBTaHJhZGRoYSwNCj4+ IA0KPj4gSSBkbyBub3Qgc2VlIGhvdyBhbiBvcmlnaW5hdG9yIGNhbiBzZXQgYW55IGZsYWcgcmVn YXJkaW5nIHRoZSBwcm90ZWN0aW9uIG9mIHRoZSBsb2NhbGx5IGF0dGFjaGVkIHByZWZpeC4NCj4+ IDxTaHJhZGRoYT4gVGhlIG9yaWdpbmF0b3IgYWR2ZXJ0aXNlcyAyIG5vZGUtc2lkcy4gT25lIHdp dGggcCBmbGFnIHNldCBhbmQgdGhlIG90aGVyIHdpdGhvdXQgdGhlIHAtZmxhZyBzZXQuDQo+PiAN Cj4+ICBJdCdzIGFsbCB0aGUgcm91dGVycyBvbiB0aGUgcGF0aCB0b3dhcmRzIHN1Y2ggcHJlZml4 IHRoYXQgbmVlZCB0byBkZWFsIHdpdGggdGhlIHByb3RlY3Rpb24uDQo+PiA8U2hyYWRkaGE+IFRo ZSByZWNlaXZpbmcgbm9kZXMgd2lsbCBkb3dubG9hZCBwcm90ZWN0ZWQgcGF0aCBmb3IgdGhlIA0K Pj4gbm9kZS1zaWQgd2l0aCBwLWZsYWcgc2V0IGFuZCBkb3dubG9hZCBVbnByb3RlY3RlZCBwYXRo IGZvciB0aGUgbm9kZS1zaWQgd2l0aCBwLWZsYWcgdW5zZXQuDQo+PiANCj4+IFNpZ25hbGluZyBh bnl0aGluZyBmcm9tIHRoZSBvcmlnaW5hdG9yIHNlZW1zIHVzZWxlc3MuDQo+PiA8U2hyYWRkaGE+ ICBGb3Igbm9kZS1zaWRzIGl0J3MgdGhlIG90aGVycyB3aG8gbmVlZCB0byBidWlsZCB0aGUgZm9y d2FyZGluZyBwbGFuZSBidXQgaXQncyBvbmx5IHRoZSBvcmlnaW5hdG9yIHdobyBjYW4gc2lnbmFs IHdoaWNoIG9mDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICBTaWQgbmVlZCB0byBiZSBidWls dCB3aXRoIHByb3RlY3Rpb24gYW5kIHdoaWNoIG5vdC4gT3RoZXIgcm91dGVycyBvbiB0aGUgcGF0 aCBjYW5ub3Qgc2lnbmFsIHRoaXMgaW5mb3JtYXRpb24uDQo+IA0KPiANCj4gDQo+PiANCj4+IFdp dGggdGhpcyB5b3UgaGF2ZSB0d28gcGF0aHMgZm9yIHRoZSBub2RlLiBPbmUgaXMgcHJvdGVjdGVk IGFuZCB0aGUgb3RoZXIgaXMgdW5wcm90ZWN0ZWQuIFRoaXMgbWVldHMgdGhlIHJlcXVpcmVtZW50 IG9mIGhhdmluZyBhbiB1bi1wcm90ZWN0ZWQgcGF0aC4NCj4+IA0KPj4gSXQncyB2ZXJ5IG11Y2gg aW4gcGFyYWxsZWwgdG8gQi1mbGFnIGluIGFkai1zaWRzLiBJdCBpcyBzaW1pbGFyIHRvIA0KPj4g YWR2ZXJ0aXNpbmcgbXVsdGlwbGUgYWRqLXNpZHMgb25lIHdpdGggQi1mbGFnIG9uIGFuZCBvdGhl ciB3aXRoIGItZmxhZyBvZmYgLCB0byBnZXQgcHJvdGVjdGVkIGFuZCB1bnByb3RlY3RlZCBBZGot c2lkcy4NCj4+IA0KPj4gdGhhbmtzLA0KPj4gUGV0ZXINCj4+IA0KPj4gT24gMTIvMjkvMTQgMDk6 MjYgLCBTaHJhZGRoYSBIZWdkZSB3cm90ZToNCj4+PiBZZXMuWW91IGFyZSByaWdodC4NCj4+PiAN Cj4+PiBMZXRzIHNheSBhIHByZWZpeCBzaWQgaGFzIGEgZmxhZyAicCBmbGFnIi4gSWYgdGhpcyBp cyBvbiBpdCBtZWFucyBidWlsZCBhIHBhdGggYW5kIHByb3ZpZGUgcHJvdGVjdGlvbi4NCj4+PiBJ ZiB0aGlzIGlzIG9mZiBpdCBtZWFucyBidWlsZCBhIHBhdGggd2l0aCBubyBwcm90ZWN0aW9uLg0K Pj4+IFRoZSByZWNlaXZlcnMgb2YgdGhlIHByZWZpeC1zaWQgd2lsbCBidWlsZCBmb3J3YXJkaW5n IHBsYW5lIGJhc2VkIG9uIHRoaXMgZmxhZy4NCj4+PiANCj4+PiBUaGUgYXBwbGljYXRpb25zIGJ1 aWxkaW5nIHRoZSBwYXRocyB3aWxsIGVpdGhlciB1c2UgcHJlZml4LXNpZHMgd2l0aCBwIGZsYWcg b24gb3Igb2ZmIGJhc2VkIG9uIHRoZSBuZWVkIG9mIHRoZSBzZXJ2aWNlLg0KPj4+IFJnZHMNCj4+ PiBTaHJhZGRoYQ0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4gRnJvbTogUGV0ZXIgUHNlbmFrIFttYWlsdG86cHBzZW5ha0BjaXNjby5jb21dDQo+Pj4gU2Vu dDogTW9uZGF5LCBEZWNlbWJlciAyOSwgMjAxNCAxOjQ5IFBNDQo+Pj4gVG86IFNocmFkZGhhIEhl Z2RlOw0KPj4+IGRyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc0B0b29s cy5pZXRmLm9yZzsNCj4+PiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lv bnNAdG9vbHMuaWV0Zi5vcmcNCj4+PiBDYzogb3NwZkBpZXRmLm9yZzsgaXNpcy13Z0BpZXRmLm9y Zw0KPj4+IFN1YmplY3Q6IFJlOiBbSXNpcy13Z10gTWFpbCByZWdhcmRpbmcgDQo+Pj4gZHJhZnQt aWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zDQo+Pj4gDQo+Pj4gU2hyYWRkaGEs DQo+Pj4gDQo+Pj4gdGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgbm9kZSB0aGF0IGlzIGFkdmVydGlz aW5nIHRoZSBub2RlLXNpZCBjYW4gbm90IGFkdmVydGlzZSBhbnkgZGF0YSByZWdhcmRpbmcgdGhl IHByb3RlY3Rpb24gb2Ygc3VjaCBwcmVmaXgsIGJlY2F1c2UgdGhlIHByZWZpeCBpcyBsb2NhbGx5 IGF0dGFjaGVkLg0KPj4+IA0KPj4+IHRoYW5rcywNCj4+PiBQZXRlcg0KPj4+IA0KPj4+IE9uIDEy LzI5LzE0IDA5OjE1ICwgU2hyYWRkaGEgSGVnZGUgd3JvdGU6DQo+Pj4+IFBldGVyLA0KPj4+PiAN Cj4+Pj4gSWYgdGhlcmUgaXMgYSBzZXJ2aWNlIHdoaWNoIGhhcyB0byB1c2UgdW4tcHJvdGVjdGVk IHBhdGggYW5kIHdoaWxlIA0KPj4+PiBidWlsZGluZyBzdWNoIGEgcGF0aCBpZiB0aGUgbm9kZS1z aWRzIE5lZWQgdG8gYmUgdXNlZCAob25lIHJlYXNvbiANCj4+Pj4gY291bGQgYmUgbGFiZWwgc3Rh Y2sgY29tcHJlc3Npb24pICwgdGhlbiB0aGVyZSBoYXMgdG8gYmUgdW5wcm90ZWN0ZWQgbm9kZS1z aWQgdGhhdCB0aGlzIHNlcnZpY2UgY2FuIG1ha2UgdXNlIG9mLg0KPj4+PiANCj4+Pj4gUHJlZml4 IC1zaWRzIGNvdWxkIGFsc28gYmUgdXNlZCB0byByZXByZXNlbnQgZGlmZmVyZW50IHNlcnZpY2Ug DQo+Pj4+IGVuZHBvaW50cyB3aGljaCBtYWtlcyBpdCBldmVuIG1vcmUgcmVsZXZhbnQgdG8gaGF2 ZSBBIG1lYW5zIG9mIHJlcHJlc2VudGluZyAgdW5wcm90ZWN0ZWQgcGF0aHMuDQo+Pj4+IA0KPj4+ PiBXb3VsZCBiZSBnb29kIHRvIGhlYXIgZnJvbSBvdGhlcnMgb24gdGhpcywgZXNwZWNpYWxseSBv cGVyYXRvcnMuDQo+Pj4+IA0KPj4+PiBSZ2RzDQo+Pj4+IFNocmFkZGhhDQo+Pj4+IA0KPj4+PiAN Cj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogUGV0ZXIgUHNlbmFr IFttYWlsdG86cHBzZW5ha0BjaXNjby5jb21dDQo+Pj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg MjksIDIwMTQgMTozNSBQTQ0KPj4+PiBUbzogU2hyYWRkaGEgSGVnZGU7DQo+Pj4+IGRyYWZ0LWll dGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc0B0b29scy5pZXRmLm9yZzsNCj4+Pj4g ZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zQHRvb2xzLmlldGYub3Jn DQo+Pj4+IENjOiBvc3BmQGlldGYub3JnOyBpc2lzLXdnQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6 IFJlOiBbSXNpcy13Z10gTWFpbCByZWdhcmRpbmcgDQo+Pj4+IGRyYWZ0LWlldGYtb3NwZi1zZWdt ZW50LXJvdXRpbmctZXh0ZW5zaW9ucw0KPj4+PiANCj4+Pj4gU2hyYWRkaGEsDQo+Pj4+IA0KPj4+ PiBub2RlLVNJRCBpcyBhZHZlcnRpc2VkIGJ5IHRoZSByb3V0ZXIgZm9yIHRoZSBwcmVmaXggdGhh dCBpcyBkaXJlY3RseSBhdHRhY2hlZCB0byBpdC4gUHJvdGVjdGlvbiBmb3Igc3VjaCBsb2NhbCBw cmVmaXggZG9lcyBub3QgbWVhbiBtdWNoLg0KPj4+PiANCj4+Pj4gdGhhbmtzLA0KPj4+PiBQZXRl cg0KPj4+PiANCj4+Pj4gT24gMTIvMjQvMTQgMTE6NTcgLCBTaHJhZGRoYSBIZWdkZSB3cm90ZToN Cj4+Pj4+IEF1dGhvcnMsDQo+Pj4+PiBXZSBoYXZlIGEgImJhY2t1cCBmbGFnIiBpbiBhZGphY2Vu Y3kgc2lkIHRvIGluZGljYXRlIHdoZXRoZXIgdGhlIA0KPj4+Pj4gbGFiZWwgaXMgcHJvdGVjdGVk IG9yIG5vdC4NCj4+Pj4+IFNpbWlsYXJseS4gSSB0aGluayB3ZSBuZWVkIGEgZmxhZyBpbiBwcmVm aXgtc2lkIGFzIHdlbGwgdG8gDQo+Pj4+PiBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBub2RlLXNpZCBp cyB0byBiZSBwcm90ZWN0ZWQgb3Igbm90Lg0KPj4+Pj4gQW55IHRob3VnaHRzIG9uIHRoaXM/DQo+ Pj4+PiBSZ2RzDQo+Pj4+PiBTaHJhZGRoYQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBJc2lzLXdnIG1h aWxpbmcgbGlzdA0KPj4+Pj4gSXNpcy13Z0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pc2lzLXdnDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IC4NCj4+ Pj4gDQo+Pj4gDQo+Pj4gLg0KPj4+IA0KPj4gDQo+PiAuDQo+PiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElzaXMtd2cgbWFpbGluZyBs aXN0DQo+IElzaXMtd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pc2lzLXdnDQoNCg== From nobody Mon Dec 29 01:41:40 2014 Return-Path: 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 B0FEB1A005F; Mon, 29 Dec 2014 01:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DeUSEdmJkt3e; Mon, 29 Dec 2014 01:41:38 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1050F1A005A; Mon, 29 Dec 2014 01:41:36 -0800 (PST) Received: from [86.180.124.183] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Y5WpM-0000Iw-L7; Mon, 29 Dec 2014 09:41:28 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=utf-8 From: Rob Shakir In-Reply-To: Date: Mon, 29 Dec 2014 09:41:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> <8673017E-4E86-4D2E-8522-DF49ED869E2D@rob.sh> To: Shraddha Hegde X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/G10gymCS1sn7JJoCM6CsdBa_lv0 Cc: "ospf@ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" , "draft-ietf-ospf-segment-routing-extensions@tools.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 09:41:39 -0000 > On 29 Dec 2014, at 09:33, Shraddha Hegde wrote: >=20 > It is likely that some application wants to use the = node-sids when the strict path for performance sensitive traffic matches = with that of the SPF for some segments or for the entire path.=20 >=20 There is nothing stopping it doing so, but it cannot deterministically = say that the path will remain coherent with the one that it expects for = multiple reasons: 1) Nodes along the path may select a subset of ECMPs, the performance of = which may vary. 2) There may be topology changes (triggered by failure or not) which = mean that the shortest-path may change. Given that either of these can result in performance variance, it=E2=80=99= s very likely (from a practical standpoint) that the traffic must be = able to live with FRRs too - hence it being unclear to me that there=E2=80= =99s a requirement for an =E2=80=98unprotected=E2=80=99 Node SID. r.= From nobody Mon Dec 29 02:12:30 2014 Return-Path: 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 C8BCD1A008B; Mon, 29 Dec 2014 02:12:25 -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 5FFgj7hLweI3; Mon, 29 Dec 2014 02:12:23 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58721A007D; Mon, 29 Dec 2014 02:12:22 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1382.namprd05.prod.outlook.com (25.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 10:12:20 +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 10:12:20 +0000 From: Shraddha Hegde To: Rob Shakir , Peter Psenak Thread-Topic: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions Thread-Index: AdAfZ+2t8gRxJR1gRJOVEF41ljB4rwD1jwiAAAAaeDAAAGH0AAAABIpwAABwSQAAABH9IAAAx7iAAABm0oAAADteMAAA79mAAAC7TkA= Date: Mon, 29 Dec 2014 10:12:20 +0000 Message-ID: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> <8673017E-4E86-4D2E-8522-DF49ED869E2D@rob.sh> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1382; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(51704005)(189002)(377454003)(199003)(99286002)(68736005)(2900100001)(33656002)(31966008)(20776003)(64706001)(46102003)(106356001)(2950100001)(66066001)(102836002)(107046002)(19580405001)(40100003)(62966003)(99396003)(93886004)(54606007)(230783001)(120916001)(74316001)(76576001)(101416001)(86362001)(97736003)(50986999)(2656002)(76176999)(54206007)(92566001)(77156002)(87936001)(122556002)(4396001)(21056001)(19580395003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1382; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 10:12:20.4385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/HqtG5LMjWRdGyu0vBEscnUU6DN8 Cc: "ospf@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 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 10:12:26 -0000 Um9iL1BldGVyLA0KDQoNCiBJIHRoaW5rIHRvZGF5IHRoZXJlIGFyZSBuZXR3b3JrcyB3aGljaCBy dW4gb25seSBvbiBTUEYgcGF0aHMgYW5kIGhhdmluZyBhIGZhY2lsaXR5IG9mICJ1bnByb3RlY3Rl ZCBub2RlLXNpZCIgaXMgdXNlZnVsIGluIG15IG9waW5pb24gDQpSYXRoZXIgdGhhbiBub3QgcHJv dmlkaW5nIHN1Y2ggYSBmYWNpbGl0eSBpbiB0aGUgcHJvdG9jb2wgYXQgYWxsLg0KDQpJIGFncmVl IHRoYXQgaWYgdGhlcmUgaXMgbm8gc3VmZmljaWVudCBpbnRlcmVzdCBvbiB0aGUgbGlzdCBpdCBj YW4gYmUgZHJvcHBlZC4gDQpJIGhvcGUgd2UgY2FuIHdhaXQgdW50aWwgdGhlIGhvbGlkYXkgc2Vh c29uIHRvIGdldCBvdmVyIHRvIGhlYXIgb3RoZXJzIG9waW5pb24gb24gdGhpcy4NCg0KUmdkcw0K U2hyYWRkaGENCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9iIFNoYWtp ciBbbWFpbHRvOnJqc0Byb2Iuc2hdIA0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAyOSwgMjAxNCAz OjExIFBNDQpUbzogU2hyYWRkaGEgSGVnZGUNCkNjOiBQZXRlciBQc2VuYWs7IGRyYWZ0LWlldGYt b3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0 Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zQHRvb2xzLmlldGYub3JnOyBvc3BmQGll dGYub3JnOyBpc2lzLXdnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lzaXMtd2ddIE1haWwgcmVn YXJkaW5nIGRyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucw0KDQoNCj4g T24gMjkgRGVjIDIwMTQsIGF0IDA5OjMzLCBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFAanVuaXBl ci5uZXQ+IHdyb3RlOg0KPiANCj4gPFNocmFkZGhhPiBJdCBpcyBsaWtlbHkgdGhhdCBzb21lIGFw cGxpY2F0aW9uIHdhbnRzIHRvIHVzZSB0aGUgbm9kZS1zaWRzIHdoZW4gdGhlIHN0cmljdCBwYXRo IGZvciBwZXJmb3JtYW5jZSBzZW5zaXRpdmUgdHJhZmZpYyBtYXRjaGVzIHdpdGggdGhhdCBvZiB0 aGUgU1BGICBmb3Igc29tZSBzZWdtZW50cyBvciBmb3IgdGhlIGVudGlyZSBwYXRoLiANCj4gDQoN ClRoZXJlIGlzIG5vdGhpbmcgc3RvcHBpbmcgaXQgZG9pbmcgc28sIGJ1dCBpdCBjYW5ub3QgZGV0 ZXJtaW5pc3RpY2FsbHkgc2F5IHRoYXQgdGhlIHBhdGggd2lsbCByZW1haW4gY29oZXJlbnQgd2l0 aCB0aGUgb25lIHRoYXQgaXQgZXhwZWN0cyBmb3IgbXVsdGlwbGUgcmVhc29uczoNCg0KMSkgTm9k ZXMgYWxvbmcgdGhlIHBhdGggbWF5IHNlbGVjdCBhIHN1YnNldCBvZiBFQ01QcywgdGhlIHBlcmZv cm1hbmNlIG9mIHdoaWNoIG1heSB2YXJ5Lg0KMikgVGhlcmUgbWF5IGJlIHRvcG9sb2d5IGNoYW5n ZXMgKHRyaWdnZXJlZCBieSBmYWlsdXJlIG9yIG5vdCkgd2hpY2ggbWVhbiB0aGF0IHRoZSBzaG9y dGVzdC1wYXRoIG1heSBjaGFuZ2UuDQoNCkdpdmVuIHRoYXQgZWl0aGVyIG9mIHRoZXNlIGNhbiBy ZXN1bHQgaW4gcGVyZm9ybWFuY2UgdmFyaWFuY2UsIGl04oCZcyB2ZXJ5IGxpa2VseSAoZnJvbSBh IHByYWN0aWNhbCBzdGFuZHBvaW50KSB0aGF0IHRoZSB0cmFmZmljIG11c3QgYmUgYWJsZSB0byBs aXZlIHdpdGggRlJScyB0b28gLSBoZW5jZSBpdCBiZWluZyB1bmNsZWFyIHRvIG1lIHRoYXQgdGhl cmXigJlzIGEgcmVxdWlyZW1lbnQgZm9yIGFuIOKAmHVucHJvdGVjdGVk4oCZIE5vZGUgU0lELg0K DQpyLg0K From nobody Mon Dec 29 02:16:48 2014 Return-Path: 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 1FD591A00A8; Mon, 29 Dec 2014 02:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W66pFQ97dFW2; Mon, 29 Dec 2014 02:16:43 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BAE1A00AE; Mon, 29 Dec 2014 02:16:42 -0800 (PST) Received: from [86.180.124.183] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Y5XNK-0000Oy-OG; Mon, 29 Dec 2014 10:16:34 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=utf-8 From: Rob Shakir In-Reply-To: Date: Mon, 29 Dec 2014 10:16:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1A0EBDEF-FF86-413E-91DB-D1E58BCDC861@rob.sh> References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> <8673017E-4E86-4D2E-8522-DF49ED869E2D@rob.sh> To: Shraddha Hegde X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/23UNYUOhdiM9B6gxe9zAwTd8h6A Cc: "ospf@ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" , "draft-ietf-ospf-segment-routing-extensions@tools.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 10:16:46 -0000 Shraddha, Do you see deployments today where there are configured RSVP-TE FRR = paths, but there are loose routed LSPs that request no FRR protection? Such a datapoint would be interesting to figure out whether we currently = have demand for this approach =E2=80=94 but clearly this would not = necessarily say anything about future requirements. Cheers, r. > On 29 Dec 2014, at 10:12, Shraddha Hegde wrote: >=20 > Rob/Peter, >=20 >=20 > I think today there are networks which run only on SPF paths and = having a facility of "unprotected node-sid" is useful in my opinion=20 > Rather than not providing such a facility in the protocol at all. >=20 > I agree that if there is no sufficient interest on the list it can be = dropped.=20 > I hope we can wait until the holiday season to get over to hear others = opinion on this. >=20 > Rgds > Shraddha >=20 >=20 > -----Original Message----- > From: Rob Shakir [mailto:rjs@rob.sh]=20 > Sent: Monday, December 29, 2014 3:11 PM > To: Shraddha Hegde > Cc: Peter Psenak; = draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; = draft-ietf-isis-segment-routing-extensions@tools.ietf.org; = ospf@ietf.org; isis-wg@ietf.org > Subject: Re: [Isis-wg] Mail regarding = draft-ietf-ospf-segment-routing-extensions >=20 >=20 >> On 29 Dec 2014, at 09:33, Shraddha Hegde = wrote: >>=20 >> It is likely that some application wants to use the = node-sids when the strict path for performance sensitive traffic matches = with that of the SPF for some segments or for the entire path.=20 >>=20 >=20 > There is nothing stopping it doing so, but it cannot deterministically = say that the path will remain coherent with the one that it expects for = multiple reasons: >=20 > 1) Nodes along the path may select a subset of ECMPs, the performance = of which may vary. > 2) There may be topology changes (triggered by failure or not) which = mean that the shortest-path may change. >=20 > Given that either of these can result in performance variance, it=E2=80=99= s very likely (from a practical standpoint) that the traffic must be = able to live with FRRs too - hence it being unclear to me that there=E2=80= =99s a requirement for an =E2=80=98unprotected=E2=80=99 Node SID. >=20 > r. From nobody Mon Dec 29 03:05:14 2014 Return-Path: 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 7F8AA1A00B0; Mon, 29 Dec 2014 03:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 RKyVph1GSgw4; Mon, 29 Dec 2014 03:04:56 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA8B1A00CF; Mon, 29 Dec 2014 03:04:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6426; q=dns/txt; s=iport; t=1419851096; x=1421060696; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XDGCOOQ+eejFoTl3FMkL7+VagYq8n12d4Ryka9jjLOs=; b=NOQda9J8MKJnYxzNNnqMc7sD3MEH4J8W+MpeK7QFCCC8W18K1e3tndo8 eHLE/Fa5Wj0I8rVJV6GEjSjmaE4dLJ1YVPKgiJ3U3da/wPRYD0wyTi8l9 aU6Cjxl7DjKh2VZs5LX3+bT7IKhmry0xrLgLmLMRx09vP+oyA/EN03LeS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEEAHo0oVStJssW/2dsb2JhbABcg1hYxmUKhXMCgSIBAQEBAX2EDAEBAQMBAQEBNTYKAQUHBAsRBAEBAQkWCAcJAwIBAgEVHwkIBgEMAQUCAQGIIAgNxB8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8MGgEBSgUHBoQjAQSXCIYEi0wig289MYEMgTcBAQE X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="286845334" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 29 Dec 2014 11:04:54 +0000 Received: from [10.61.89.185] (ams3-vpn-dhcp6586.cisco.com [10.61.89.185]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBTB4qZc026853; Mon, 29 Dec 2014 11:04:53 GMT Message-ID: <54A13555.2020208@cisco.com> Date: Mon, 29 Dec 2014 12:04:53 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Shraddha Hegde , "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" , "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/8r2GZXVGzqBYotx35fpywN7i16E Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 11:05:03 -0000 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. >> 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. >> 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. >> 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 >>>>> >>>> >>>> . >>>> >>> >>> . >>> >> >> . >> > > . > From nobody Mon Dec 29 13:27:43 2014 Return-Path: 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 56A981A9103; Mon, 29 Dec 2014 13:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ht7Hf8lKmqVH; Mon, 29 Dec 2014 13:27:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA51A908B; Mon, 29 Dec 2014 13:27:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229212738.17994.7309.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 13:27:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OnzmlX5-NEBheBCeZjUjZasiq78 Cc: ospf@ietf.org, ospf-chairs@tools.ietf.org, draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org Subject: [OSPF] Barry Leiba's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 21:27:40 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ospf-te-metric-extensions-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of minor, non-blocking comments, just looking for a little clarification: -- Section 7 -- I can't imagine that the "SHOULD" in the first paragraph is an appropriate 2119 key word: no one can tell whether or not care was taken, so this can't be a protocol issue. Please just say "Therefore it is important to set these values carefully." For the remaining "SHOULD"s, "SHOULD NOT", and "RECOMMENDED" in this section: remembering that "SHOULD" means that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course," how can someone reading this understand and weigh those implications? I can't: I have no idea why these recommendations are being made, and what the implications are of making different choices. Can you help me here? Or are these just recommended values, in the lower-case, plain English sense? From nobody Mon Dec 29 22:12:01 2014 Return-Path: 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 2C4591A1B84; Mon, 29 Dec 2014 22:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[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 hN9xRHBvvUfN; Mon, 29 Dec 2014 22:11:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5236D1A0AF1; Mon, 29 Dec 2014 22:11:56 -0800 (PST) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (25.160.107.139) by BY1PR0501MB1382.namprd05.prod.outlook.com (25.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 30 Dec 2014 06:11:33 +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; Tue, 30 Dec 2014 06:11:33 +0000 From: Shraddha Hegde To: Peter Psenak , "draft-ietf-ospf-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+2t8gRxJR1gRJOVEF41ljB4rwD1jwiAAAAaeDAAAGH0AAAABIpwAABwSQAAABH9IAAAx7iAAAAQr4AABGtNgAAn0juw Date: Tue, 30 Dec 2014 06:11:32 +0000 Message-ID: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> <54A13555.2020208@cisco.com> In-Reply-To: <54A13555.2020208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1382; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(479174004)(51704005)(189002)(377454003)(199003)(64706001)(20776003)(68736005)(99286002)(107046002)(15975445007)(31966008)(2900100001)(33656002)(105586002)(2950100001)(106356001)(102836002)(66066001)(19580405001)(40100003)(99396003)(93886004)(54606007)(230783001)(120916001)(74316001)(76576001)(101416001)(86362001)(97736003)(50986999)(2656002)(76176999)(87936001)(122556002)(92566001)(54206007)(62966003)(77156002)(46102003)(4396001)(21056001)(19580395003)(2201001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1382; 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: 30 Dec 2014 06:11:32.3661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/lTNLyk_U9-K0zNziV-X0pMwvz3o Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 06:11:59 -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. > can you give an example of such a service and a reasoning why such servic= e would want to avoid local protection along the path? Heavy bandwidth services are potential candidates. The network is well pla= nned and well provisioned for primary path but same is not true for backup = paths. Diverting heavy bandwidth services along protection path can disrupt the ot= her services on that path, they are better-off un-protected so that an even= t in the network Would result in disconnection and a retry for such services. Rgds Shraddha -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com]=20 Sent: Monday, December 29, 2014 4:35 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.o= rg; 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-exten= sions 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 tod= ay. 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;=20 > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;=20 > draft-ietf-isis-segment-routing-extensions@tools.ietf.org > Cc: ospf@ietf.org; isis-wg@ietf.org > Subject: Re: [Isis-wg] Mail regarding=20 > draft-ietf-ospf-segment-routing-extensions > > Shraddha, > > I do not see how an originator of the node-sid can mandate a protection f= or the prefix on other routers. What if there is no backup available on a c= ertain node along the path? > > The parallel with the B-flag in adj-sids is not right - in case of adj-si= d 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=20 >> 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. >> The originator advertises 2 node-sids. One with p flag set an= d the other without the p-flag set. >> >> It's all the routers on the path towards such prefix that need to dea= l with the protection. >> The receiving nodes will download protected path for the=20 >> 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. >> For node-sids it's the others who need to build the forwardi= ng 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 othe= r 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=20 >> advertising multiple adj-sids one with B-flag on and other with b-flag o= ff , 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 th= is 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=20 >>> draft-ietf-ospf-segment-routing-extensions >>> >>> Shraddha, >>> >>> the problem is that the node that is advertising the node-sid can not a= dvertise any data regarding the protection of such prefix, because the pref= ix 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=20 >>>> building such a path if the node-sids Need to be used (one reason=20 >>>> could be label stack compression) , then there has to be unprotected n= ode-sid that this service can make use of. >>>> >>>> Prefix -sids could also be used to represent different service=20 >>>> endpoints which makes it even more relevant to have A means of represe= nting 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=20 >>>> draft-ietf-ospf-segment-routing-extensions >>>> >>>> Shraddha, >>>> >>>> node-SID is advertised by the router for the prefix that is directly a= ttached 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=20 >>>>> label is protected or not. >>>>> Similarly. I think we need a flag in prefix-sid as well to=20 >>>>> 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 >>>>> >>>> >>>> . >>>> >>> >>> . >>> >> >> . >> > > . > From nobody Tue Dec 30 08:22:14 2014 Return-Path: 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 196251A000E; Tue, 30 Dec 2014 08:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 CrZyZpvtuEpF; Tue, 30 Dec 2014 08:22:04 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB781A000C; Tue, 30 Dec 2014 08:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8938; q=dns/txt; s=iport; t=1419956524; x=1421166124; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8X1GVOX7HCEeAiV9Kj0RlDcZiPYvuVLSMuLiAcProIs=; b=c1qxHL+2jeLTKCtJityHFNf4ubCZZO8nEymT0bZ44rWjpL3EaGEdQ2hl yZzAHMN4S/GR/AmPnb0lHKYtqE+Q13v6ke3LRe+6QflFUVzf5QlUga70J LtAmIAD5XgbfzWcEiaZE/NqOVELylqhKdRkYmO/fGYSogVnmIzJhcjWDt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAMrPolStJV2Q/2dsb2JhbABcgmQiUlgExkgKhXkCgQcWAQEBAQF9hAwBAQEDAQEBATc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIiBwIAQzFCQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEig2EfxoBAR4GJgUHAgSDEIETBY4VmkMig25vgQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="109250573" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 30 Dec 2014 16:22:03 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sBUGM3Mt020117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Dec 2014 16:22:03 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 30 Dec 2014 10:22:02 -0600 From: "Les Ginsberg (ginsberg)" To: Shraddha Hegde , "Peter Psenak (ppsenak)" , "draft-ietf-ospf-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: AQHQI/eNjO3OMGSsP0morl+oLI2n+5yoTnXw Date: Tue, 30 Dec 2014 16:22:01 +0000 Message-ID: References: <54A10B35.4030301@cisco.com> <54A10E78.6030006@cisco.com> <54A11188.8040301@cisco.com> <54A1173D.6000200@cisco.com> <54A13555.2020208@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.167.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/5fRSyFtIKumOjMbzV-_KGbx1op0 Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 16:22:13 -0000 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 pat= h) is a function of the topology - not the link. If there is a topology ch= ange it is quite likely that a given link will change from being a protectE= D link to being a protectING link (or vice versa). So what you propose rega= rding node-SIDs would not work. In the use case you mention below if you don't want a certain class of traf= fic to flow on a given link it requires a link attribute which is persisten= t across topology changes. There are ways to do that - using Adj-SIDs is on= e 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@tool= s.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-routin= g-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 servic= e would want to avoid local protection along the path? Heavy bandwidth services are potential candidates. The network is well pla= nned and well provisioned for primary path but same is not true for backup = paths. Diverting heavy bandwidth services along protection path can disrupt the ot= her services on that path, they are better-off un-protected so that an even= t in the network Would result in disconnection and a retry for such service= s. 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.o= rg; 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-exten= sions 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 tod= ay. 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=20 > draft-ietf-ospf-segment-routing-extensions > > Shraddha, > > I do not see how an originator of the node-sid can mandate a protection f= or the prefix on other routers. What if there is no backup available on a c= ertain node along the path? > > The parallel with the B-flag in adj-sids is not right - in case of adj-si= d 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=20 >> 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. >> The originator advertises 2 node-sids. One with p flag set an= d the other without the p-flag set. >> >> It's all the routers on the path towards such prefix that need to dea= l with the protection. >> The receiving nodes will download protected path for the=20 >> 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. >> For node-sids it's the others who need to build the forwardi= ng 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 othe= r 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=20 >> advertising multiple adj-sids one with B-flag on and other with b-flag o= ff , 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 th= is 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=20 >>> draft-ietf-ospf-segment-routing-extensions >>> >>> Shraddha, >>> >>> the problem is that the node that is advertising the node-sid can not a= dvertise any data regarding the protection of such prefix, because the pref= ix 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=20 >>>> building such a path if the node-sids Need to be used (one reason=20 >>>> could be label stack compression) , then there has to be unprotected n= ode-sid that this service can make use of. >>>> >>>> Prefix -sids could also be used to represent different service=20 >>>> endpoints which makes it even more relevant to have A means of represe= nting 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=20 >>>> draft-ietf-ospf-segment-routing-extensions >>>> >>>> Shraddha, >>>> >>>> node-SID is advertised by the router for the prefix that is directly a= ttached 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=20 >>>>> label is protected or not. >>>>> Similarly. I think we need a flag in prefix-sid as well to=20 >>>>> 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