From nobody Mon Sep 1 09: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 02D171A01F3 for ; Mon, 1 Sep 2014 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DlksVXc09t4E for ; Mon, 1 Sep 2014 09:07:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB421A035E for ; Mon, 1 Sep 2014 09:07:34 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C45672AC104; Mon, 1 Sep 2014 18:07:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id AC43C18004F; Mon, 1 Sep 2014 18:07:32 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 18:07:33 +0200 From: To: "Acee Lindem (acee)" , "ospf@ietf.org" Thread-Topic: Poll for WG adoption of draft-hegde-ospf-node-admin-tag Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvsdvvg Date: Mon, 1 Sep 2014 16:07:32 +0000 Message-ID: <15734_1409587652_540499C4_15734_4858_1_53C29892C857584299CBF5D05346208A071DB06E@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.1.153022 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Q79JnyqF13qzeYC1l3pWATjBZCs Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 16:08:21 -0000 Support. This is useful for network operator to express policy based on node capabil= ities/performance/roles (e.g. PE/P/ASBR/BNG, access/aggregation/POP/Core, o= dd/even.). In particular I support uses cases 2, 3 and TE/explicit routing policy (a l= a CSPF excluding "even" or "ASBR" nodes, in particular in the SPRING contex= t). 2 comments: - I can provide text & ascii art for the above additional explicit routing = use cases use case if authors agree - :s/ I-D.litkowski-rtgwg-lfa-manageability/ I-D.ietf-rtgwg-lfa-manageabili= ty Thanks, Regards, Bruno ---- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Monday, August 25, 2014 11:18 PM To: ospf@ietf.org Subject: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag There are situations where node level policy is required and an OSPF advert= ised admin tag simplifies this. For example, advertisement of remote-LFA el= igibility. Please indicate your support or objections to adopting this draft as an OSP= F WG document.=A0 Thanks, Acee=A0 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Sep 1 14:35: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 C71B51A0ACD for ; Mon, 1 Sep 2014 14:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982] autolearn=no 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 MpPiS4aY_Aq5 for ; Mon, 1 Sep 2014 14:35:04 -0700 (PDT) Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 99CDE1A08BE for ; Mon, 1 Sep 2014 14:35:03 -0700 (PDT) Received: from prz-workstation.zeta2.ch (108-228-12-76.lightspeed.sntcca.sbcglobal.net [108.228.12.76]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPSA id 94A86894F for ; Mon, 1 Sep 2014 23:34:56 +0200 (CEST) Message-ID: <5404E67E.6050407@zeta2.ch> Date: Mon, 01 Sep 2014 14:34:54 -0700 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ospf@ietf.org References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> In-Reply-To: X-TagToolbar-Keys: D20140901143454535 Content-Type: multipart/alternative; boundary="------------070301000206050703080906" X-MailScanner-ID: 94A86894F.AAEF4 X-MailScanner: Found to be clean X-MailScanner-From: prz@zeta2.ch Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pUZEYUhipdDqbT7pUC-45RRyYco Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt 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 Sep 2014 21:35:05 -0000 This is a multi-part message in MIME format. --------------070301000206050703080906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Comments: a) section 1. introduction last line > the existing LSAs will be replaced _BY_ TLV-based extended LSAs. b) section 2. It may be well writing a sentence or two what should happen if an OSPFv2 Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11 changes) and what should happen if the same prefix appears in two different flooding scopes with different information (ignore prefix in both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it open may lead to different treatement per router and surprising effects It may be also helpful to add that if an opaque extended is present but the prefix (of the according type) is not in the standard LSAs, such information must be disregarded. c) section 2.1 > Multiple OSPF Extended Prefix > TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but > all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA > MUST have the same flooding scope. may be misleading. Since they are in a opaque, the flooding scope is controlled by opaque. If the type-5 vs. type-3 is meant than 'flooding scope' must be disassociated between 'opaque flooidng scope' and 'route-type flooding scope [as in we don't flood type-1 across ABRs]' ? d) I think it may be a valid suggestion to implementors that (for every version) the according LSA SHOULD be flooded _before_ the opaque LSA is flooded (which can be tad tricky [but doable] if the opaque carries a bunch of those]). Yes, with reordering of flooding etc. it's not a guarantee for anything but a good practice to give the protocol a chance to distribute the referent (LSA) before distributing any references (opaques) and additionally, will make sure that LSAs which are far more important normally get out the box before opaques. --- tony On 08/13/2014 06:12 AM, Acee Lindem (acee) wrote: > Hi, > > This new draft describes the generic prefix/link attribute opaque LSAs > that were previously included in the OSPFv2 Segment Routing draft. The > opaque LSAs described in this draft can be used by other OSPF WG candidate > drafts. There are already two implementations of the draft as part of > segment routing interoperability testing. Please read and comment. > Thanks, > Acee > --------------070301000206050703080906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Comments:

a)   section 1. introduction last line

> the existing LSAs will be replaced _BY_ TLV-based extended LSAs.

b) section 2.

It may be well writing a sentence or two what should happen if an OSPFv2 Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11 changes) and what should happen if the same prefix appears in two different flooding scopes with different information (ignore prefix in both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it open may lead to different treatement per router and surprising effects

It may be also helpful to add that if an opaque extended is present but the prefix (of the according type) is not in the standard LSAs, such information must be disregarded.

c) section 2.1

> Multiple OSPF Extended Prefix
> TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but
> all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA
> MUST have the same flooding scope.

may be misleading. Since they are in a opaque, the flooding scope is controlled by opaque. If  the type-5 vs. type-3 is meant than  'flooding scope' must be disassociated between 'opaque flooidng scope' and 'route-type flooding scope [as in we don't flood type-1 across ABRs]'  ?


d)
I think it may be a valid suggestion to implementors that (for every version) the  according  LSA  SHOULD be flooded _before_ the opaque LSA is flooded (which can be tad tricky [but doable] if the opaque carries a bunch of those]).  Yes, with reordering of flooding etc. it's not a guarantee for anything but a good practice to give the protocol a chance to distribute the referent (LSA) before distributing any references (opaques) and additionally, will make sure that  LSAs which are far more important normally get out the box before opaques.


--- tony


On 08/13/2014 06:12 AM, Acee Lindem (acee) wrote:
Hi, 

This new draft describes the generic prefix/link attribute opaque LSAs
that were previously included in the OSPFv2 Segment Routing draft.  The
opaque LSAs described in this draft can be used by other OSPF WG candidate
drafts. There are already two implementations of the draft as part of
segment routing interoperability testing. Please read and comment.
Thanks,
Acee

--------------070301000206050703080906-- From nobody Tue Sep 2 00:25: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 204BA1A00B0 for ; Tue, 2 Sep 2014 00:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 lGNFEpVCiCwb for ; Tue, 2 Sep 2014 00:25:43 -0700 (PDT) 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 7B4B81A00AA for ; Tue, 2 Sep 2014 00:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3343; q=dns/txt; s=iport; t=1409642742; x=1410852342; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=TpJ+GRIKIsXTTBA9BZHXV/6E80/V10JxPWlD5ZmDvQk=; b=jCZiV4rF3aVuYimEHgZN8RBTNh80I760QHKh6Y5KiGnVdERzlgOQANFL /pK4J5LosXMz2pYDiURbgxroifWRGqvxGuSOhrcgGzYgXEt+G8/QLNb8w Xo1JbUDie6bInARMh8u/lbhT5XTz1KwwapGZ6+XKGNn0vHj6ElbfVQl+m A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAHBwBVStJssW/2dsb2JhbABZg2BXx3wKh08BgSB3hAMBAQEDAQEBATUvBwkBEQsYCRYPCQMCAQIBFScJBgEMBgIBAYg2CA25VwETBI51X4RMAQSOfI1ghzeNZ4IbgUg7L4EGgUkBAQE X-IronPort-AV: E=Sophos;i="5.04,447,1406592000"; d="scan'208";a="158108750" 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; 02 Sep 2014 07:25:38 +0000 Received: from [10.55.51.206] (ams-ppsenak-87113.cisco.com [10.55.51.206]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s827PcxO012964; Tue, 2 Sep 2014 07:25:38 GMT Message-ID: <540570F2.4050507@cisco.com> Date: Tue, 02 Sep 2014 09:25:38 +0200 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: "A. Przygienda" , ospf@ietf.org References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <5404E67E.6050407@zeta2.ch> In-Reply-To: <5404E67E.6050407@zeta2.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/H7IpIMB4_xiS1ICNfkPjr2S_zqw Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt 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 Sep 2014 07:25:46 -0000 Hi Tony, please see inline: On 9/1/14 23:34 , A. Przygienda wrote: > Comments: > > a) section 1. introduction last line > > > the existing LSAs will be replaced _BY_ TLV-based extended LSAs. ok, > > b) section 2. > > It may be well writing a sentence or two what should happen if an OSPFv2 > Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11 > changes) and what should happen if the same prefix appears in two > different flooding scopes with different information (ignore prefix in > both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it > open may lead to different treatement per router and surprising effects as far as the information in the two LSAs are the same, having the prefix in two LSAs with different flooding scopes is not a problem - happens today with regular LSAs.) The problem would be if the content of TLVs associated with the prefix is controversial, in which case it would be a defect on the originator side. > > It may be also helpful to add that if an opaque extended is present but > the prefix (of the according type) is not in the standard LSAs, such > information must be disregarded. no, that is a valid case. One may want to advertise some extended prefix attributes without advertising the prefix's reachability. > > c) section 2.1 > > > Multiple OSPF Extended Prefix > > TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but > > all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA > > MUST have the same flooding scope. > > may be misleading. Since they are in a opaque, the flooding scope is > controlled by opaque. If the type-5 vs. type-3 is meant than 'flooding > scope' must be disassociated between 'opaque flooidng scope' and > 'route-type flooding scope [as in we don't flood type-1 across ABRs]' ? LSA can only have single flooding scope, so all information inside LSA is limited to that flooding scope. That is what was meant by the above texts. > > > d) > I think it may be a valid suggestion to implementors that (for every > version) the according LSA SHOULD be flooded _before_ the opaque LSA > is flooded (which can be tad tricky [but doable] if the opaque carries a > bunch of those]). Yes, with reordering of flooding etc. it's not a > guarantee for anything but a good practice to give the protocol a chance > to distribute the referent (LSA) before distributing any references > (opaques) and additionally, will make sure that LSAs which are far more > important normally get out the box before opaques. as I said, not flooding regular LSA, only extended LSA is a valid case. thanks, Peter > > > --- tony > > > On 08/13/2014 06:12 AM, Acee Lindem (acee) wrote: >> Hi, >> >> This new draft describes the generic prefix/link attribute opaque LSAs >> that were previously included in the OSPFv2 Segment Routing draft. The >> opaque LSAs described in this draft can be used by other OSPF WG candidate >> drafts. There are already two implementations of the draft as part of >> segment routing interoperability testing. Please read and comment. >> Thanks, >> Acee >> > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Tue Sep 2 01:24:08 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 686141A00D6 for ; Tue, 2 Sep 2014 01:24:05 -0700 (PDT) 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 zyX2w3bDCQnU for ; Tue, 2 Sep 2014 01:24:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E69F1A0127 for ; Tue, 2 Sep 2014 01:24:02 -0700 (PDT) Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB521.namprd05.prod.outlook.com (10.141.72.13) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 08:24:00 +0000 Received: from hannes-mba.local (193.110.55.13) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 08:23:58 +0000 Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 455922A6F62; Tue, 2 Sep 2014 10:23:42 +0200 (CEST) Date: Tue, 2 Sep 2014 10:23:42 +0200 From: Hannes Gredler To: "A. Przygienda" Message-ID: <20140902082342.GB39341@juniper.net> References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <5404E67E.6050407@zeta2.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5404E67E.6050407@zeta2.ch> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.13] X-ClientProxiedBy: DB4PR06CA0037.eurprd06.prod.outlook.com (25.160.40.165) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-Forefront-PRVS: 0322B4EDE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(199003)(105586002)(74502001)(23726002)(106356001)(4396001)(77982001)(76506005)(77096002)(31966008)(74662001)(86362001)(87976001)(46406003)(102836001)(46102001)(33656002)(95666004)(107046002)(230783001)(92726001)(50466002)(47776003)(50986999)(21056001)(85306004)(54356999)(76176999)(83506001)(83322001)(80022001)(76482001)(101416001)(92566001)(110136001)(81542001)(97756001)(83072002)(85852003)(90102001)(99396002)(64706001)(20776003)(66066001)(36756003)(81342001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/phc0Yev2rS_CP1-m387xJFjneWk Cc: ospf@ietf.org Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt 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 Sep 2014 08:24:05 -0000 hi tony, requiring send-side ordering is certainly intended well, but that in itself does not guarantee ordered delivery at the receiving end :-/. IOW in case you have an application that needs both the 1) prefix-LSA and the 2) extended-prefix-LSA you need to have the logic that checks presence of 1) at the receiving end anyway. rather than doing things on the send-side let me suggest to check if you have got your act together during route-computation time. (this is a bit akin to IS-IS fragment zero handling - ala - if frag zero is not present then all non-zero frag content has to be disregarded). HTH, /hannes On Mon, Sep 01, 2014 at 02:34:54PM -0700, A. Przygienda wrote: [ ... ] | d) | I think it may be a valid suggestion to implementors that (for every | version) the according LSA SHOULD be flooded _before_ the opaque LSA is | flooded (which can be tad tricky [but doable] if the opaque carries a | bunch of those]). Yes, with reordering of flooding etc. it's not a | guarantee for anything but a good practice to give the protocol a chance | to distribute the referent (LSA) before distributing any references | (opaques) and additionally, will make sure that LSAs which are far more | important normally get out the box before opaques. | | --- tony From nobody Tue Sep 2 06:40: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 60A1B1A8829 for ; Tue, 2 Sep 2014 06:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 C6rqSMjZ0505 for ; Tue, 2 Sep 2014 06:40:30 -0700 (PDT) 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 DF67D1A8758 for ; Tue, 2 Sep 2014 06:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4451; q=dns/txt; s=iport; t=1409665062; x=1410874662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QssAkOiedoEEE8Ft9BSFCbcM9ibe7UPzU7eNYgdya/Q=; b=k3wUK6TTQe0ang99z0AuoTnr2S+6lBRxuCKtEUClChD/SXkcMeELqsKZ us3VBbD0zwyMFGg10UJz+oR+TOXuGhaADYsPviFIdhql70Xsmvof/oQvW wuzEpLmLAtp6tl0XeDmSehPWXVNrIogQlPTfLeK8ZYJzNIzQ9bflOafCL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFABfHBVStJA2E/2dsb2JhbABZgw1TTQoEyAcKh0wBgRAWd4QDAQEBAwEBAQE3LQcJAgULAgEIGB4QJwscCQIEDgWIOggNuk4BEwSOdSUzB4MvgR0FjnyCNYsrlR6CG4FGbIEGQoEHAQEB X-IronPort-AV: E=Sophos;i="5.04,449,1406592000"; d="scan'208";a="351735342" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 02 Sep 2014 13:37:41 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s82DbfpL015233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 13:37:41 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 08:37:40 -0500 From: "Acee Lindem (acee)" To: "Peter Psenak (ppsenak)" Thread-Topic: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt Thread-Index: AQHPtlGQNLZvkWuqU0uFf/90h1EvfZvOlLMAgB6rngCAAKUNAIAAZ/CA Date: Tue, 2 Sep 2014 13:37:40 +0000 Message-ID: <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> In-Reply-To: <540570F2.4050507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/i9DW4zah0N8w7AGohHVl_rbzEdU Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt 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 Sep 2014 13:40:33 -0000 Hi Peter, Tony,=20 On Sep 2, 2014, at 3:25 AM, Peter Psenak wrote: > Hi Tony, >=20 > please see inline: >=20 > On 9/1/14 23:34 , A. Przygienda wrote: >> Comments: >>=20 >> a) section 1. introduction last line >>=20 >> > the existing LSAs will be replaced _BY_ TLV-based extended LSAs. >=20 > ok, >=20 >>=20 >> b) section 2. >>=20 >> It may be well writing a sentence or two what should happen if an OSPFv2 >> Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11 >> changes) and what should happen if the same prefix appears in two >> different flooding scopes with different information (ignore prefix in >> both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it >> open may lead to different treatement per router and surprising effects >=20 > as far as the information in the two LSAs are the same, having the prefix= in two LSAs with different flooding scopes is not a problem - happens toda= y with regular LSAs.) The problem would be if the content of TLVs associate= d with the prefix is controversial, in which case it would be a defect on t= he originator side. This is another case where the segment routing mapping server requirement m= akes this more complicated. I think the guidance for the case should be to = give preference to the information in the LSA with area flooding scope.=20 >=20 >>=20 >> It may be also helpful to add that if an opaque extended is present but >> the prefix (of the according type) is not in the standard LSAs, such >> information must be disregarded. >=20 > no, that is a valid case. One may want to advertise some extended prefix = attributes without advertising the prefix's reachability. >=20 >>=20 >> c) section 2.1 >>=20 >> > Multiple OSPF Extended Prefix >> > TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but >> > all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA >> > MUST have the same flooding scope. >>=20 >> may be misleading. Since they are in a opaque, the flooding scope is >> controlled by opaque. If the type-5 vs. type-3 is meant than 'flooding >> scope' must be disassociated between 'opaque flooidng scope' and >> 'route-type flooding scope [as in we don't flood type-1 across ABRs]' ? >=20 > LSA can only have single flooding scope, so all information inside LSA is= limited to that flooding scope. That is what was meant by the above texts. Actually, I had considered removing this statement when I separated the gen= eric protocol extensions from the SR specific draft.=20 >=20 >>=20 >>=20 >> d) >> I think it may be a valid suggestion to implementors that (for every >> version) the according LSA SHOULD be flooded _before_ the opaque LSA >> is flooded (which can be tad tricky [but doable] if the opaque carries a >> bunch of those]). Yes, with reordering of flooding etc. it's not a >> guarantee for anything but a good practice to give the protocol a chance >> to distribute the referent (LSA) before distributing any references >> (opaques) and additionally, will make sure that LSAs which are far more >> important normally get out the box before opaques. >=20 > as I said, not flooding regular LSA, only extended LSA is a valid case. In any case, an application using extended attributes will need to be trigg= ered by the extended prefix/link attribute LSAs. The advertising router ma= y originate one or both of them independently. I will try to capture this d= isjointness in a paragraph.=20 Thanks, Acee=20 >=20 > thanks, > Peter >>=20 >>=20 >> --- tony >>=20 >>=20 >> On 08/13/2014 06:12 AM, Acee Lindem (acee) wrote: >>> Hi, >>>=20 >>> This new draft describes the generic prefix/link attribute opaque LSAs >>> that were previously included in the OSPFv2 Segment Routing draft. The >>> opaque LSAs described in this draft can be used by other OSPF WG candid= ate >>> drafts. There are already two implementations of the draft as part of >>> segment routing interoperability testing. Please read and comment. >>> Thanks, >>> Acee >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Tue Sep 2 23:28: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 82E8F1A6F8F for ; Tue, 2 Sep 2014 23:28:25 -0700 (PDT) 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 F8mW_iLTem_M for ; Tue, 2 Sep 2014 23:28:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2F51A0011 for ; Tue, 2 Sep 2014 23:28:22 -0700 (PDT) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 06:28:19 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.106]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.106]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 06:28:19 +0000 From: Shraddha Hegde To: Dhruv Dhody , "Acee Lindem (acee)" Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvpIRSAgAXa+UA= Date: Wed, 3 Sep 2014 06:28:19 +0000 Message-ID: <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(24454002)(13464003)(51704005)(377454003)(199003)(189002)(77096002)(4396001)(77982001)(87936001)(64706001)(20776003)(46102001)(99286002)(33646002)(106356001)(76576001)(19580405001)(31966008)(106116001)(92566001)(74662001)(15975445006)(19580395003)(105586002)(86362001)(90102001)(74502001)(83322001)(85306004)(2656002)(66066001)(80022001)(108616004)(101416001)(230783001)(50986999)(21056001)(99396002)(76176999)(76482001)(107046002)(83072002)(85852003)(54356999)(81342001)(95666004)(74316001)(81542001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB126; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; 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/mGslzRxn_4bPT29VJFFoYYtZfCM Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 06:28:25 -0000 Dhruv, Thanks for detailed review and comments. Pls see in-line for the response. Rgds Shraddha -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Saturday, August 30, 2014 6:22 PM To: Acee Lindem (acee) Cc: ospf@ietf.org Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag Hi, I have read the document and I support it for WG adoption. I have following comments, that can be handled later (1) Section 4.1 OLD: The format of the TLVs within the body of an RI LSA is the same as the format used by the Traffic Engineering Extensions to OSPF [RFC3630]. The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of each TLV is: NEW: As per [RFC4970], the format of the TLVs within the body of an RI LSA is= the same as the format used by the Traffic Engineering Extensions to OSPF [RFC3630]. The RI LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of the per-node administrative tag TLV is: END Accept. Will be updated in the next revision. Also, it should be stated - if are more than one instance of this TLV in RI LSA are allowed. More than one instance of the TLV can be added in same RI-LSA or = in a multiple instance as defined In draft-acee-ospf-rfc4970bis-00.txt - Minimum one tag must be present in the TLV Accept. - What happens if the implementation does not know the Interpretation of th= e tag value This is mentioned in section 4.2, However will add explicit ment= ion regarding the scenario you mentioned. (2) It should be explicitly stated that - No IANA registry is required to s= tore the meaning or interpretation of.the tag values. It's mentioned in the section 4.2 that no well known tag values= will be defined by this document. (3) Backward compatibility - few lines may be added to state that as per [R= FC4970], unknown TLV would be silently ignored. Accept Nits - Avoid using reference in abstract - Expand LFA on first use - Administrative Tag TLV or 'per-node Administrative Tag' : consistent nami= ng through the document would be nice Accept. Regards, Dhruv On Tue, Aug 26, 2014 at 2:48 AM, Acee Lindem (acee) wrote: > There are situations where node level policy is required and an OSPF=20 > advertised admin tag simplifies this. For example, advertisement of=20 > remote-LFA eligibility. > > Please indicate your support or objections to adopting this draft as=20 > an OSPF WG document. > > Thanks, > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From nobody Wed Sep 3 01:08: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 94DA21A0073 for ; Wed, 3 Sep 2014 01:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 0v1E7066urAa for ; Wed, 3 Sep 2014 01:08:42 -0700 (PDT) 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 786D71A003B for ; Wed, 3 Sep 2014 01:08:40 -0700 (PDT) Received: from [86.180.125.226] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XP5cK-0004hJ-QA; Wed, 03 Sep 2014 09:08:36 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <53FCAB34.7020602@cisco.com> Date: Wed, 3 Sep 2014 09:08:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/nRWGG9WF9MCsAiQTfsrOfMfYJyw Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 08:08:44 -0000 Hi Peter. On 26 Aug 2014, at 16:43, Peter Psenak wrote: >=20 > On 8/26/14 17:32 , Hannes Gredler wrote: >>=20 >> operators want to assign node-tags as per router function (ABR, PE, = core) and then >> the LFA-selection becomes much easier to specify. - e.g. >> - only pick a LFA that does not cross another PE router. >>=20 >> similarily it is desirable for "LFA tunnel termination" >> to put out a constraint which says >> - only pick a PQ neighbor which has node tag 'X' >=20 > my point is that with the above approach you have to: > 1. On candidate PQ nodes configure the tag X > 2. on all other nodes configure "only pick a PQ neighbor which has = node tag 'X'" >=20 > It's (2) which makes me feel uncomfortable, as it's a config to be = applied to many nodes. I=92m unclear on how one would solve this =97 the key thing is that = there are number of scenarios where it is *operator* preference rather = than node capabilities that mean that we want to select a particular = node for some certain application. This preference may be on a = per-calculating node basis. If this is the case, then a single = capability that says that a particular target node is capable of acting = in a particular role is not sufficient. (Consider this scenario: - rtr-A is in country 1. - rtr-B is in country 2. - Both rtr-A and rtf-B are capable of acting as PQ nodes,and = need to act as such for =91local=92 nodes (i.e., those in the same = country as them). - rtr-A should never select rtr-B as a PQ. In this case, we need some tag that specifies country, as well as some = tag that specifies that it is a valid PQ node. We then need specific = policy on rtr-A and rtr-B to implement this policy.) It is very typical that where we have such policy implementations, then = we need to configure the behaviour on a per-node basis. This is = especially true where policies must consider characteristics of the = topology. >>=20 >> i found it always strange that we for TE (as an example for >> constraining paths) we have got ways to tag links, but >> not way to tag nodes - that draft aims to fix that. >=20 > I'm not against tagging nodes as such. What worries me if we end up = using node tags for signalling capabilities of node. As per the above, I do not think that this mechanism replaces any = capability, it just gives an operator a means to be more granular than = the binary =93supported=94/=93not supported=94 view that a flag = indicating capabilities does. I, of course, support the adoption of this draft as a co-author. Cheers, r. From nobody Wed Sep 3 01:14: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 448531A8549 for ; Wed, 3 Sep 2014 01:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 naxttN-h6Gkf for ; Wed, 3 Sep 2014 01:14:21 -0700 (PDT) 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 481E81A00AA for ; Wed, 3 Sep 2014 01:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2800; q=dns/txt; s=iport; t=1409732002; x=1410941602; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1fELtnVi0xr7KS7QPpifGaR1WGWg/mhtusndTQer5lE=; b=PVmmPDN3wry7H1uM8iQYQtQIxfzFfENgupYGkEQBaqbgj55M/DmcrJ/O /sVJAMBQVAMinlEHyX0HUfD1PiHZwf0kduYiuy8SwhIAsE/BV+ITTLXrG 7LF86fZ52KoOmnUXS4HzbW0iS/BmzMdw08P5SuTLEfchcr3df28dgZYnS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAFnNBlStJssW/2dsb2JhbABahDfQEAGBI3eEAwEBAQMBMgEFQAEQCw4KCRYPCQMCAQIBRQYNAQUCAQGINgiqb5JJARePTQeETAEEnFyHN41ng2M7L4JPAQEB X-IronPort-AV: E=Sophos;i="5.04,455,1406592000"; d="scan'208";a="164247185" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 03 Sep 2014 08:13:19 +0000 Received: from [10.55.51.206] (ams-ppsenak-87113.cisco.com [10.55.51.206]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s838DHEL008115; Wed, 3 Sep 2014 08:13:17 GMT Message-ID: <5406CD9D.2070905@cisco.com> Date: Wed, 03 Sep 2014 10:13:17 +0200 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: Rob Shakir References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> 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/-IayoIJT_npDSk4dRNju_Y4RzyE Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 08:14:23 -0000 Hi Rob, On 9/3/14 10:08 , Rob Shakir wrote: > Hi Peter. > > On 26 Aug 2014, at 16:43, Peter Psenak wrote: > >> >> On 8/26/14 17:32 , Hannes Gredler wrote: >>> >>> operators want to assign node-tags as per router function (ABR, PE, core) and then >>> the LFA-selection becomes much easier to specify. - e.g. >>> - only pick a LFA that does not cross another PE router. >>> >>> similarily it is desirable for "LFA tunnel termination" >>> to put out a constraint which says >>> - only pick a PQ neighbor which has node tag 'X' >> >> my point is that with the above approach you have to: >> 1. On candidate PQ nodes configure the tag X >> 2. on all other nodes configure "only pick a PQ neighbor which has node tag 'X'" >> >> It's (2) which makes me feel uncomfortable, as it's a config to be applied to many nodes. > > I’m unclear on how one would solve this — the key thing is that there are number of scenarios where it is *operator* preference rather than node capabilities that mean that we want to select a particular node for some certain application. This preference may be on a per-calculating node basis. If this is the case, then a single capability that says that a particular target node is capable of acting in a particular role is not sufficient. > > (Consider this scenario: > - rtr-A is in country 1. > - rtr-B is in country 2. > - Both rtr-A and rtf-B are capable of acting as PQ nodes,and need to act as such for ‘local’ nodes (i.e., those in the same country as them). > - rtr-A should never select rtr-B as a PQ. > In this case, we need some tag that specifies country, as well as some tag that specifies that it is a valid PQ node. We then need specific policy on rtr-A and rtr-B to implement this policy.) > > It is very typical that where we have such policy implementations, then we need to configure the behaviour on a per-node basis. This is especially true where policies must consider characteristics of the topology. > > >>> >>> i found it always strange that we for TE (as an example for >>> constraining paths) we have got ways to tag links, but >>> not way to tag nodes - that draft aims to fix that. >> >> I'm not against tagging nodes as such. What worries me if we end up using node tags for signalling capabilities of node. > > As per the above, I do not think that this mechanism replaces any capability, it just gives an operator a means to be more granular than the binary “supported”/“not supported” view that a flag indicating capabilities does. I understand. My point was that admin tags should not be used in cases where only a binary capability is signaled. thanks, Peter > > I, of course, support the adoption of this draft as a co-author. > > Cheers, > r. > > > . > From nobody Wed Sep 3 01:18: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 B11741A702A for ; Wed, 3 Sep 2014 01:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 RQ5a62h4VXgI for ; Wed, 3 Sep 2014 01:17:58 -0700 (PDT) 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 CF8F11A00DD for ; Wed, 3 Sep 2014 01:16:15 -0700 (PDT) Received: from [86.180.125.226] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XP5je-0004i6-Ry; Wed, 03 Sep 2014 09:16:10 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <5406CD9D.2070905@cisco.com> Date: Wed, 3 Sep 2014 09:16:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/RVotcllmyw0uo86wnGnZMmzgefM Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 08:18:00 -0000 Hi Peter, On 3 Sep 2014, at 09:13, Peter Psenak wrote: >> As per the above, I do not think that this mechanism replaces any = capability, it just gives an operator a means to be more granular than = the binary =93supported=94/=93not supported=94 view that a flag = indicating capabilities does. >=20 > I understand. My point was that admin tags should not be used in cases = where only a binary capability is signaled. ACK, I completely agree. Perhaps we should add something into the draft = that the admin-tag should not be used for such a purpose. Cheers, r.= From nobody Wed Sep 3 01:21:33 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 C06BC1A0055 for ; Wed, 3 Sep 2014 01:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 bUd58Nz_QRWo for ; Wed, 3 Sep 2014 01:21:29 -0700 (PDT) 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 124401A86ED for ; Wed, 3 Sep 2014 01:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=703; q=dns/txt; s=iport; t=1409732447; x=1410942047; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=E7qO/yn7F59J3FEIziwvBdMaxyxA37zD5mFVPMuFWVI=; b=LNDH+KMuigC8pTWd9GRNI9fZHv6G3StUxSZH3ZiXrmdOnBdqws5R693m 0CqJ8dy6vowBeK+PeEGa5cX1kKhMtbooRGSCNmc/aBDp5F16SDlGSgHw4 +CWWugC+v1s+LtzOrtZfxVAUO7z2AutqSAe80dZlBnEqXzDMKz+AvwiKv o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEACzOBlStJssW/2dsb2JhbABahDfQEgGBI3eEAwEBAQMBMgEFQAEQCw4KCRYPCQMCAQIBRQYNAQUCAQGINgi9OQEXj00HhEwBBJxchzeNZ4NjOy+CTwEBAQ X-IronPort-AV: E=Sophos;i="5.04,455,1406592000"; d="scan'208";a="159518028" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 03 Sep 2014 08:20:45 +0000 Received: from [10.55.51.206] (ams-ppsenak-87113.cisco.com [10.55.51.206]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s838Kjr6017787; Wed, 3 Sep 2014 08:20:45 GMT Message-ID: <5406CF5D.7040002@cisco.com> Date: Wed, 03 Sep 2014 10:20:45 +0200 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: Rob Shakir References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> In-Reply-To: <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/rx6kgD3KOBxbk8ypu0vSookEBKM Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 08:21:30 -0000 Hi Rob, On 9/3/14 10:16 , Rob Shakir wrote: > Hi Peter, > > On 3 Sep 2014, at 09:13, Peter Psenak wrote: > >>> As per the above, I do not think that this mechanism replaces any capability, it just gives an operator a means to be more granular than the binary “supported”/“not supported” view that a flag indicating capabilities does. >> >> I understand. My point was that admin tags should not be used in cases where only a binary capability is signaled. > > ACK, I completely agree. Perhaps we should add something into the draft that the admin-tag should not be used for such a purpose. I would certainly appreciate that. thanks, Peter > > Cheers, > r. > From nobody Wed Sep 3 03:25: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 D49E71A892B for ; Wed, 3 Sep 2014 03:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ukiR8-BFZqqu for ; Wed, 3 Sep 2014 03:25:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9E61A891F for ; Wed, 3 Sep 2014 03:25:10 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 834E23B42D8; Wed, 3 Sep 2014 12:25:08 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 53F4027C07D; Wed, 3 Sep 2014 12:25:08 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 12:25:08 +0200 From: To: Peter Psenak , Rob Shakir Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag Thread-Index: AQHPx1AVtvZWODn3ike5gZjbZZ1ijZvvLvew Date: Wed, 3 Sep 2014 10:25:07 +0000 Message-ID: <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> In-Reply-To: <5406CF5D.7040002@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.100319 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0K3_VShfyMN57l0rAuiEutDR6JY Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 10:25:13 -0000 Hi Peter, Rob, +1 on Rob's comment regarding the use of admin tag for expressing operator = policy (rather than spec/feature capability) 1 point in lined below=20 > From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM >=20 > Hi Rob, >=20 > On 9/3/14 10:16 , Rob Shakir wrote: > > Hi Peter, > > > > On 3 Sep 2014, at 09:13, Peter Psenak wrote: > > > >>> As per the above, I do not think that this mechanism replaces any > capability, it just gives an operator a means to be more granular than the > binary "supported"/"not supported" view that a flag indicating capabiliti= es > does. > >> > >> I understand. My point was that admin tags should not be used in cases > where only a binary capability is signaled. > > > > ACK, I completely agree. Perhaps we should add something into the draft= that the admin-tag should not be used for such a purpose. > I would certainly appreciate that. I agree as a general rule. Yet IMHO we should not kill this possibility. In= particular for feature allowing incremental deployment & interaction with = non-compliant nodes. One example would have been Remote LFA (RLFA): - the PLR (FRR node) needs to be RLFA compliant. Therefore (potential) comm= unication between PLR regarding their capabilities can be done using IANA/i= mplemented code point. - the PQ node (Merge Point) does not need to be RLFA compliant. And we shou= ld keep this property to ease incremental deployment. Therefore communicati= on between PQ and PLR regarding PQ capabilities should/may be done using no= de tag. RLFA spec could have defined an IANA registered node tag to be use= d by PQ (configured by the network operator) to exclude them as PQ candidat= e. e.g. for PQ node not accepting T-LDP session or nodes which should not b= e used as PQ per policy. Thanks, Bruno =20 >=20 > thanks, > Peter >=20 > > > > Cheers, > > r. > > >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 3 03: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 66D4B1A891F for ; Wed, 3 Sep 2014 03:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 aPnwn6rVfk1b for ; Wed, 3 Sep 2014 03:32:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF4C1A8A47 for ; Wed, 3 Sep 2014 03:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3297; q=dns/txt; s=iport; t=1409740347; x=1410949947; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j/ehW3F8i8S4Kys+zjZPT5UXfg6U26dVowaYxo3H2IE=; b=kjTLIXrm+hhA+0NEtr2ojXZJn5MUV43zT/TyygRs/yk1CdroYF/UoX2k Y+772WgV1dCibFzH11Dl9tZdKMo+xxVPdVT+nHbEBYtF55zjrbt1Uv4Vj wRMJ29Khn3Gz0kUPysLqUaS+J2xtE220EtjFF+WhEi7NT+puEARW4xpAq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEADftBlStJssW/2dsb2JhbABag2BXyEIKh0wBgSd3hAMBAQEDAQEBATU2CgEQCxUBAgkWDwkDAgECARUwBgEMAQUCAQGINggNvR0BEwSOaxEBUAeETAEEnFyHN41ng2M7L4EPgUABAQE X-IronPort-AV: E=Sophos;i="5.04,456,1406592000"; d="scan'208";a="163711620" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Sep 2014 10:32:25 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s83AWOTh013590; Wed, 3 Sep 2014 10:32:25 GMT Message-ID: <5406EE38.2010504@cisco.com> Date: Wed, 03 Sep 2014 12:32:24 +0200 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: bruno.decraene@orange.com, Rob Shakir References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/xsLBdWQ1JS-4ERuC_4ZSexQkf9w Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 10:32:29 -0000 Hi Bruno, On 9/3/14 12:25 , bruno.decraene@orange.com wrote: > Hi Peter, Rob, > > +1 on Rob's comment regarding the use of admin tag for expressing operator policy (rather than spec/feature capability) > > 1 point in lined below > >> From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM >> >> Hi Rob, >> >> On 9/3/14 10:16 , Rob Shakir wrote: >>> Hi Peter, >>> >>> On 3 Sep 2014, at 09:13, Peter Psenak wrote: >>> >>>>> As per the above, I do not think that this mechanism replaces any >> capability, it just gives an operator a means to be more granular than the >> binary "supported"/"not supported" view that a flag indicating capabilities >> does. >>>> >>>> I understand. My point was that admin tags should not be used in cases >> where only a binary capability is signaled. >>> >>> ACK, I completely agree. Perhaps we should add something into the draft that the admin-tag should not be used for such a purpose. > >> I would certainly appreciate that. > > I agree as a general rule. Yet IMHO we should not kill this possibility. In particular for feature allowing incremental deployment & interaction with non-compliant nodes. > One example would have been Remote LFA (RLFA): > - the PLR (FRR node) needs to be RLFA compliant. Therefore (potential) communication between PLR regarding their capabilities can be done using IANA/implemented code point. > - the PQ node (Merge Point) does not need to be RLFA compliant. And we should keep this property to ease incremental deployment. Therefore communication between PQ and PLR regarding PQ capabilities should/may be done using node tag. RLFA spec could have defined an IANA registered node tag to be used by PQ (configured by the network operator) to exclude them as PQ candidate. e.g. for PQ node not accepting T-LDP session or nodes which should not be used as PQ per policy. why is "IANA registered node tag" any better then IANA registered capability bit in the above case? thanks, Peter > > Thanks, > Bruno > >> >> thanks, >> Peter >> >>> >>> Cheers, >>> r. >>> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > From nobody Wed Sep 3 04:01: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 7CD691A86E9 for ; Wed, 3 Sep 2014 04:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rNd1n1NZlOxl for ; Wed, 3 Sep 2014 04:01:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8E21A86F7 for ; Wed, 3 Sep 2014 04:01:42 -0700 (PDT) Received: from hannes-mba.local (193.110.55.17) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 11:01:40 +0000 Received: from hannes-mba.local (localhost [127.0.0.1]) by hannes-mba.local (Postfix) with ESMTP id 0CF9C2AFB5F; Wed, 3 Sep 2014 13:01:28 +0200 (CEST) Message-ID: <5406F507.3080307@juniper.net> Date: Wed, 3 Sep 2014 13:01:27 +0200 From: Hannes Gredler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Peter Psenak , , Rob Shakir References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5406EE38.2010504@cisco.com> In-Reply-To: <5406EE38.2010504@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [193.110.55.17] X-ClientProxiedBy: DB3PR01CA0056.eurprd01.prod.exchangelabs.com (10.242.133.159) To CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 032334F434 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(189002)(199003)(24454002)(479174003)(51704005)(74662001)(74502001)(31966008)(80316001)(83322001)(59896002)(93886004)(15202345003)(76506005)(85306004)(33656002)(87266999)(99396002)(76176999)(54356999)(36756003)(21056001)(65816999)(19580395003)(102836001)(50986999)(50466002)(83506001)(64706001)(83072002)(85852003)(90102001)(65806001)(101416001)(79102001)(80022001)(15975445006)(66066001)(65956001)(86362001)(77982001)(81342001)(64126003)(92566001)(105586002)(76482001)(4396001)(107046002)(46102001)(92726001)(230783001)(81542001)(95666004)(87976001)(20776003)(106356001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/naNj4LGCdzK_DNH6Oa1f6bz9j0s Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 11:01:45 -0000 hi peter, the question is not so much which registry is better; we have existing proof-point (rlfa-spec not containing any capabilities) that there may be the possibility that: - a well-known, protocol specific tag does not exist - the operator problem (excluding/including certain nodes from PQ capability) still does exist so it looks like we have a practical case in favor of bruno's argument. let me draw also some analogy to tagging of IP prefixes here: draft-hegde-ospf-node-admin-tag is a generic vehicle just as http://datatracker.ietf.org/doc/rfc5130/ has been conceived for IP prefixes. - it is correct for the problem described in RFC5130 we could have been applying application-specific bits in IP prefixes that control the leaking behavior. however a different model has been chosen: 1) use generic, application-context-free tags for a prefix 2) write the leaking policy which refers to those tags. i find the flexibility of that model appealing and i'd like to have something similar for "nodes" on link-state graphs. /hannes On 9/3/14 12:32, Peter Psenak wrote: >> >> I agree as a general rule. Yet IMHO we should not kill this >> possibility. In particular for feature allowing incremental deployment >> & interaction with non-compliant nodes. >> One example would have been Remote LFA (RLFA): >> - the PLR (FRR node) needs to be RLFA compliant. Therefore (potential) >> communication between PLR regarding their capabilities can be done >> using IANA/implemented code point. >> - the PQ node (Merge Point) does not need to be RLFA compliant. And we >> should keep this property to ease incremental deployment. Therefore >> communication between PQ and PLR regarding PQ capabilities should/may >> be done using node tag. RLFA spec could have defined an IANA >> registered node tag to be used by PQ (configured by the network >> operator) to exclude them as PQ candidate. e.g. for PQ node not >> accepting T-LDP session or nodes which should not be used as PQ per >> policy. > > why is "IANA registered node tag" any better then IANA registered > capability bit in the above case? From nobody Wed Sep 3 04:50: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 569481A008F for ; Wed, 3 Sep 2014 04:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 ny20jfT3e2Cm for ; Wed, 3 Sep 2014 04:50:12 -0700 (PDT) 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 1E5DB1A0086 for ; Wed, 3 Sep 2014 04:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2839; q=dns/txt; s=iport; t=1409745012; x=1410954612; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MNdWZA2wROIKMuHHFtX01DShn0q32KhNMv4iT6izEgs=; b=fiZQbhB/BxOVlnVXpMMhytPrz2BEYk0CE8eNqJHeSuqktSPrvq1Mfzzg GCq9OCd9+02HgROYl6pYWJFqyRgWCuP3GXSMUSeIRyO8lHq4pirxvnln0 /zkfL18cE5634ay/JwFN++phRepo1Eru8kv1OGHD587OCwOYu5dypXfr7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIGAP7/BlStJssW/2dsb2JhbABag2BYyEuHTAGBJ3eEAwEBAQMBOEABEAsYCRYPCQMCAQIBRQYBDAEHAQEXiB8IDb0pAReOamMHhEwBBJVfhn2BW4VcjWeDYzuCfgEBAQ X-IronPort-AV: E=Sophos;i="5.04,457,1406592000"; d="scan'208";a="164431608" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 03 Sep 2014 11:50:07 +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 s83Bo6ke012700; Wed, 3 Sep 2014 11:50:07 GMT Message-ID: <5407006E.8030100@cisco.com> Date: Wed, 03 Sep 2014 13:50:06 +0200 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: Hannes Gredler , bruno.decraene@orange.com, Rob Shakir References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5406EE38.2010504@cisco.com> <5406F507.3080307@juniper.net> In-Reply-To: <5406F507.3080307@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/3_dJx9b0X1TFPkgNOaYuWQSnVfU Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 11:50:14 -0000 Hi Hannes, On 9/3/14 13:01 , Hannes Gredler wrote: > hi peter, > > the question is not so much which registry is better; > > we have existing proof-point (rlfa-spec not containing any capabilities) > that there may be the possibility that: > > - a well-known, protocol specific tag does not exist > - the operator problem (excluding/including certain nodes > from PQ capability) still does exist > > so it looks like we have a practical case in favor of bruno's argument. well, a more practical solution for the above _capability_ case would be to define a bit in OSPF Router Informational Capabilities TLV. The reason is that the meaning of the bit is defined and as such no other configuration is required on any other nodes except the PQ ones. > > > let me draw also some analogy to tagging of IP prefixes here: > draft-hegde-ospf-node-admin-tag is a generic vehicle just as > http://datatracker.ietf.org/doc/rfc5130/ has been conceived for > IP prefixes. - it is correct for the problem described in > RFC5130 we could have been applying application-specific > bits in IP prefixes that control the leaking behavior. > > however a different model has been chosen: > > 1) use generic, application-context-free tags for a prefix > 2) write the leaking policy which refers to those tags. > > i find the flexibility of that model appealing and i'd > like to have something similar for "nodes" on link-state > graphs. as I expressed multiple times, I have no issue with the node admin tags draft as such. My concern is related to the usage of the admin tags for signaling capabilities for which there is a better existing solution available. thanks, Peter > > /hannes > > On 9/3/14 12:32, Peter Psenak wrote: >>> >>> I agree as a general rule. Yet IMHO we should not kill this >>> possibility. In particular for feature allowing incremental deployment >>> & interaction with non-compliant nodes. >>> One example would have been Remote LFA (RLFA): >>> - the PLR (FRR node) needs to be RLFA compliant. Therefore (potential) >>> communication between PLR regarding their capabilities can be done >>> using IANA/implemented code point. >>> - the PQ node (Merge Point) does not need to be RLFA compliant. And we >>> should keep this property to ease incremental deployment. Therefore >>> communication between PQ and PLR regarding PQ capabilities should/may >>> be done using node tag. RLFA spec could have defined an IANA >>> registered node tag to be used by PQ (configured by the network >>> operator) to exclude them as PQ candidate. e.g. for PQ node not >>> accepting T-LDP session or nodes which should not be used as PQ per >>> policy. >> >> why is "IANA registered node tag" any better then IANA registered >> capability bit in the above case? > . > From nobody Wed Sep 3 05:10: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 261E81A010C for ; Wed, 3 Sep 2014 05:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MxiGsZesBERF for ; Wed, 3 Sep 2014 05:09:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F651A01CA for ; Wed, 3 Sep 2014 05:09:50 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 488BA191359; Wed, 3 Sep 2014 14:09:48 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 2831918008D; Wed, 3 Sep 2014 14:09:48 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 14:09:47 +0200 From: To: Peter Psenak Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag Thread-Index: AQHPx2JbyO8pjHIi00S0Dq3yQYr7dZvvTVHQ Date: Wed, 3 Sep 2014 12:09:47 +0000 Message-ID: <11709_1409746188_5407050C_11709_11179_1_53C29892C857584299CBF5D05346208A071EC5F6@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5406EE38.2010504@cisco.com> In-Reply-To: <5406EE38.2010504@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.3.102122 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/7haCwNfMXvUCB3yoUtomw5mar2c Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 12:09:59 -0000 Hi Peter, > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, Septembe= r 03, 2014 12:32 PM >=20 > Hi Bruno, >=20 > On 9/3/14 12:25 , bruno.decraene@orange.com wrote: > > Hi Peter, Rob, > > > > +1 on Rob's comment regarding the use of admin tag for expressing > > +operator policy (rather than spec/feature capability) > > > > 1 point in lined below > > > >> From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM > >> > >> Hi Rob, > >> > >> On 9/3/14 10:16 , Rob Shakir wrote: > >>> Hi Peter, > >>> > >>> On 3 Sep 2014, at 09:13, Peter Psenak wrote: > >>> > >>>>> As per the above, I do not think that this mechanism replaces any > >> capability, it just gives an operator a means to be more granular > >> than the binary "supported"/"not supported" view that a flag > >> indicating capabilities does. > >>>> > >>>> I understand. My point was that admin tags should not be used in > >>>> cases > >> where only a binary capability is signaled. > >>> > >>> ACK, I completely agree. Perhaps we should add something into the > draft that the admin-tag should not be used for such a purpose. > > > >> I would certainly appreciate that. > > > > I agree as a general rule. Yet IMHO we should not kill this possibility= . In > particular for feature allowing incremental deployment & interaction with > non-compliant nodes. > > One example would have been Remote LFA (RLFA): > > - the PLR (FRR node) needs to be RLFA compliant. Therefore (potential) > communication between PLR regarding their capabilities can be done using > IANA/implemented code point. > > - the PQ node (Merge Point) does not need to be RLFA compliant. And we > should keep this property to ease incremental deployment. Therefore > communication between PQ and PLR regarding PQ capabilities should/may > be done using node tag. RLFA spec could have defined an IANA registered > node tag to be used by PQ (configured by the network operator) to exclude > them as PQ candidate. e.g. for PQ node not accepting T-LDP session or nod= es > which should not be used as PQ per policy. >=20 > why is "IANA registered node tag" any better then IANA registered capabil= ity > bit in the above case? We need the value to be able to be set/cleared by configuration (by the net= work operator) in order to allow for PQ node not compliant with RLFA to adv= ertise it. Node-admin tag clear matches this requirement. I assumed that the capability bits were controlled by the software and not = by the network operator and hence could not be used. However, I realize tha= t this is an assumption that may be incorrect as I'm not familiar with OSPF= implementations (as we are mostly using ISIS). If all OSPF implementations= allow the network operator to control any bits (or at least the non alloca= ted/supported ones) I think I agree that such bit could equally be used. Ho= wever, after quickly reading the RFC, I'm not seeing that those bits MUST/S= HOULD be configurable by configuration. Hence we can't really guaranty that= any (future) implementation would allow this. Thanks, Bruno > thanks, > Peter >=20 >=20 >=20 > > > > Thanks, > > Bruno > > > >> > >> thanks, > >> Peter > >> > >>> > >>> Cheers, > >>> r. > >>> > >> > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www.ietf.org/mailman/listinfo/ospf > > > > > __________________________________________________________ > ____________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > . > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 3 05:19:33 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 A67F31A8707 for ; Wed, 3 Sep 2014 05:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 j6iFVxclfGhk for ; Wed, 3 Sep 2014 05:19:16 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F041A010C for ; Wed, 3 Sep 2014 05:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6026; q=dns/txt; s=iport; t=1409746755; x=1410956355; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1oQMulMY80vkVimpLiwb1BBVw1nIWn4qyi2Vh9OTWeU=; b=WbX0b4ZYoEvcLBrSeFfsiGIHORv4tqrA/Q8JRYpzKRme35nkY5cw2oSj lH0bsVK3qO3iT59wS6ZsY4dV0cI7/Hl4NN87ChKArPFQI+GUasZro+iRv TKtxD3tFN33E7uN+yUL8TGljmbU6sQN138TT3emCIMI9u/QNw4owR6hf5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEANUFB1StJssW/2dsb2JhbABZg2BXyEIKh0wBgSZ3hAMBAQEDAQEBATU2CgEQCxUBAgkWCAcJAwIBAgEVHxETAQUCAQGINggNvTgBEwSOaxEBUAeETAEEmBmEQ4c3jWeDYzsvgQ+BQAEBAQ X-IronPort-AV: E=Sophos;i="5.04,457,1406592000"; d="scan'208";a="163804030" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Sep 2014 12:19:12 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s83CJCrC013060; Wed, 3 Sep 2014 12:19:12 GMT Message-ID: <54070740.4000906@cisco.com> Date: Wed, 03 Sep 2014 14:19:12 +0200 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: bruno.decraene@orange.com References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5406EE38.2010504@cisco.com> <11709_1409746188_5407050C_11709_11179_1_53C29892C857584299CBF5D05346208A071EC5F6@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <11709_1409746188_5407050C_11709_11179_1_53C29892C857584299CBF5D05346208A071EC5F6@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/1RokNoLlmdcMEuTTJ73JCWnDjKs Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 12:19:24 -0000 Hi Bruno, On 9/3/14 14:09 , bruno.decraene@orange.com wrote: > Hi Peter, > >> From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, September 03, 2014 12:32 PM >> >> Hi Bruno, >> >> On 9/3/14 12:25 , bruno.decraene@orange.com wrote: >>> Hi Peter, Rob, >>> >>> +1 on Rob's comment regarding the use of admin tag for expressing >>> +operator policy (rather than spec/feature capability) >>> >>> 1 point in lined below >>> >>>> From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM >>>> >>>> Hi Rob, >>>> >>>> On 9/3/14 10:16 , Rob Shakir wrote: >>>>> Hi Peter, >>>>> >>>>> On 3 Sep 2014, at 09:13, Peter Psenak wrote: >>>>> >>>>>>> As per the above, I do not think that this mechanism replaces any >>>> capability, it just gives an operator a means to be more granular >>>> than the binary "supported"/"not supported" view that a flag >>>> indicating capabilities does. >>>>>> >>>>>> I understand. My point was that admin tags should not be used in >>>>>> cases >>>> where only a binary capability is signaled. >>>>> >>>>> ACK, I completely agree. Perhaps we should add something into the >> draft that the admin-tag should not be used for such a purpose. >>> >>>> I would certainly appreciate that. >>> >>> I agree as a general rule. Yet IMHO we should not kill this possibility. In >> particular for feature allowing incremental deployment & interaction with >> non-compliant nodes. >>> One example would have been Remote LFA (RLFA): >>> - the PLR (FRR node) needs to be RLFA compliant. Therefore (potential) >> communication between PLR regarding their capabilities can be done using >> IANA/implemented code point. >>> - the PQ node (Merge Point) does not need to be RLFA compliant. And we >> should keep this property to ease incremental deployment. Therefore >> communication between PQ and PLR regarding PQ capabilities should/may >> be done using node tag. RLFA spec could have defined an IANA registered >> node tag to be used by PQ (configured by the network operator) to exclude >> them as PQ candidate. e.g. for PQ node not accepting T-LDP session or nodes >> which should not be used as PQ per policy. >> >> why is "IANA registered node tag" any better then IANA registered capability >> bit in the above case? > > We need the value to be able to be set/cleared by configuration (by the network operator) in order to allow for PQ node not compliant with RLFA to advertise it. > Node-admin tag clear matches this requirement. > I assumed that the capability bits were controlled by the software and not by the network operator and hence could not be used. However, I realize that this is an assumption that may be incorrect as I'm not familiar with OSPF implementations (as we are mostly using ISIS). If all OSPF implementations allow the network operator to control any bits (or at least the non allocated/supported ones) I think I agree that such bit could equally be used. However, after quickly reading the RFC, I'm not seeing that those bits MUST/SHOULD be configurable by configuration. Hence we can't really guaranty that any (future) implementation would allow this. RFC4970 does not pose any restrictions on setting of a capability bits in OSPF Router Informational Capabilities TLV. Some bits may be set based on the software capabilities of the originator but others may be set based on the configuration and willingness of the originator to perform certain functionality. The flexibility is there. thanks, Peter > > Thanks, > Bruno >> thanks, >> Peter >> >> >> >>> >>> Thanks, >>> Bruno >>> >>>> >>>> thanks, >>>> Peter >>>> >>>>> >>>>> Cheers, >>>>> r. >>>>> >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> >> __________________________________________________________ >> ____________ >>> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les >> pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be >> distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete >> this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >>> Thank you. >>> >>> . >>> > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > From nobody Wed Sep 3 06:50: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 1AB971A02F0 for ; Wed, 3 Sep 2014 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 CFSIVojWuXXV for ; Wed, 3 Sep 2014 06:50:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC5E1A030C for ; Wed, 3 Sep 2014 06:50:31 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id B6F46C21D5; Wed, 3 Sep 2014 15:50:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 9B154C804F; Wed, 3 Sep 2014 15:50:29 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 15:50:29 +0200 From: To: Peter Psenak Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag Thread-Index: AQHPx3FG1CFHXZCiDEe77DyMQAVFwZvva5ig Date: Wed, 3 Sep 2014 13:50:28 +0000 Message-ID: <11232_1409752229_54071CA5_11232_18273_1_53C29892C857584299CBF5D05346208A071EC7B4@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5406EE38.2010504@cisco.com> <11709_1409746188_5407050C_11709_11179_1_53C29892C857584299CBF5D05346208A071EC5F6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <54070740.4000906@cisco.com> In-Reply-To: <54070740.4000906@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.3.120921 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/qavbWi2086HzNaV3TYo4V8dPF0A Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 13:50:36 -0000 Hi Peter, > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, Septembe= r 03, 2014 2:19 PM >=20 > Hi Bruno, >=20 > On 9/3/14 14:09 , bruno.decraene@orange.com wrote: > > Hi Peter, > > > >> From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, > >> September 03, 2014 12:32 PM > >> > >> Hi Bruno, > >> > >> On 9/3/14 12:25 , bruno.decraene@orange.com wrote: > >>> Hi Peter, Rob, > >>> > >>> +1 on Rob's comment regarding the use of admin tag for expressing > >>> +operator policy (rather than spec/feature capability) > >>> > >>> 1 point in lined below > >>> > >>>> From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM > >>>> > >>>> Hi Rob, > >>>> > >>>> On 9/3/14 10:16 , Rob Shakir wrote: > >>>>> Hi Peter, > >>>>> > >>>>> On 3 Sep 2014, at 09:13, Peter Psenak wrote: > >>>>> > >>>>>>> As per the above, I do not think that this mechanism replaces > >>>>>>> any > >>>> capability, it just gives an operator a means to be more granular > >>>> than the binary "supported"/"not supported" view that a flag > >>>> indicating capabilities does. > >>>>>> > >>>>>> I understand. My point was that admin tags should not be used in > >>>>>> cases > >>>> where only a binary capability is signaled. > >>>>> > >>>>> ACK, I completely agree. Perhaps we should add something into the > >> draft that the admin-tag should not be used for such a purpose. > >>> > >>>> I would certainly appreciate that. > >>> > >>> I agree as a general rule. Yet IMHO we should not kill this > >>> possibility. In > >> particular for feature allowing incremental deployment & interaction > >> with non-compliant nodes. > >>> One example would have been Remote LFA (RLFA): > >>> - the PLR (FRR node) needs to be RLFA compliant. Therefore > >>> (potential) > >> communication between PLR regarding their capabilities can be done > >> using IANA/implemented code point. > >>> - the PQ node (Merge Point) does not need to be RLFA compliant. And > >>> we > >> should keep this property to ease incremental deployment. Therefore > >> communication between PQ and PLR regarding PQ capabilities > should/may > >> be done using node tag. RLFA spec could have defined an IANA > >> registered node tag to be used by PQ (configured by the network > >> operator) to exclude them as PQ candidate. e.g. for PQ node not > >> accepting T-LDP session or nodes which should not be used as PQ per > policy. > >> > >> why is "IANA registered node tag" any better then IANA registered > >> capability bit in the above case? > > > > We need the value to be able to be set/cleared by configuration (by the > network operator) in order to allow for PQ node not compliant with RLFA to > advertise it. > > Node-admin tag clear matches this requirement. > > I assumed that the capability bits were controlled by the software and = not > by the network operator and hence could not be used. However, I realize > that this is an assumption that may be incorrect as I'm not familiar with= OSPF > implementations (as we are mostly using ISIS). If all OSPF implementations > allow the network operator to control any bits (or at least the non > allocated/supported ones) I think I agree that such bit could equally be = used. > However, after quickly reading the RFC, I'm not seeing that those bits > MUST/SHOULD be configurable by configuration. Hence we can't really > guaranty that any (future) implementation would allow this. >=20 > RFC4970 does not pose any restrictions on setting of a capability bits in= OSPF > Router Informational Capabilities TLV. Some bits may be set based on the > software capabilities of the originator but others may be set based on the > configuration and willingness of the originator to perform certain > functionality. The flexibility is there. Agreed that the flexibility is there in the spec. But the feature may not b= e implemented hence used. So if we add a text in node-admin-tag to forbid _= any_ capability advertisement, I think we should also add a text to mandate= the ability for the SP to configure RFC 4970 capability bits advertisement. Thanks, Bruno >=20 > thanks, > Peter >=20 > > > > Thanks, > > Bruno > >> thanks, > >> Peter > >> > >> > >> > >>> > >>> Thanks, > >>> Bruno > >>> > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>>> > >>>>> Cheers, > >>>>> r. > >>>>> > >>>> > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ospf > >>> > >>> > >> > __________________________________________________________ > >> ____________ > >>> ___________________________________________________ > >>> > >>> Ce message et ses pieces jointes peuvent contenir des informations > >>> confidentielles ou privilegiees et ne doivent donc pas etre > >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>> ce message par erreur, veuillez le signaler a l'expediteur et le > >>> detruire ainsi que les > >> pieces jointes. Les messages electroniques etant susceptibles > >> d'alteration, Orange decline toute responsabilite si ce message a ete > >> altere, deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or > >>> privileged information that may be protected by law; they should not > >>> be > >> distributed, used or copied without authorisation. > >>> If you have received this email in error, please notify the sender > >>> and delete > >> this message and its attachments. > >>> As emails may be altered, Orange is not liable for messages that > >>> have been > >> modified, changed or falsified. > >>> Thank you. > >>> > >>> . > >>> > > > > > > > __________________________________________________________ > ____________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > . > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 3 07:10: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 29F7F1A033E for ; Wed, 3 Sep 2014 07:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 EGCL85KGttff for ; Wed, 3 Sep 2014 07:09:59 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B551A0331 for ; Wed, 3 Sep 2014 07:09:59 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id rp18so9660579iec.40 for ; Wed, 03 Sep 2014 07:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9NzEzTsDK9G71ey+a0m3AmBcHmBd8rLJ25QorBQ8oVA=; b=jTURBrCXV7Pmxb5ZBVqzsWjuypWc+CeXiSi8qRp3wvjnxpUEsUkWmkWWe+GCvNckbb zRATZKsG1qv+rX5oQkRGLeTxc9UjYcqkclFd2+bU2qq+XIfTewKajDUJkgxu+Gt1FrzX aLzoE2vfjjP1wGNeP+zkmwYR3GuRfM0PoFsvfc6J+IobmkMwqsPgfP4sSOTLQcWKXWDs i39B3DRlIHkzrFtPDYVYkIXmcu2OWNSKwkQX22cjvbRjhykYB0SW4dctXAIDck9rSHXT ZmLTaqAkkfXEAxs0OEOJuflPoPTAwLo3OucpUT2HvnW4zzqeulEo+ep29BuFYsr0hhHS EDlQ== MIME-Version: 1.0 X-Received: by 10.43.79.135 with SMTP id zq7mr23710758icb.33.1409753398875; Wed, 03 Sep 2014 07:09:58 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.89.232 with HTTP; Wed, 3 Sep 2014 07:09:58 -0700 (PDT) In-Reply-To: <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com> References: <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com> Date: Wed, 3 Sep 2014 19:39:58 +0530 X-Google-Sender-Auth: 4p61d8LtCdqAbBfQyrpLpg20m8Q Message-ID: From: Dhruv Dhody To: Shraddha Hegde Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pyXF_Ha2JH9EwpMimurilF8IwtA Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 14:10:01 -0000 Hi Shraddha, Thanks for your reply, snipping to the open point... > Also, it should be stated > - if are more than one instance of this TLV in RI LSA are allowed. > > More than one instance of the TLV can be added in same RI-LSA or in a multiple instance as defined > In draft-acee-ospf-rfc4970bis-00.txt > Okay, text may be added to reflect this. > (2) It should be explicitly stated that - No IANA registry is required to store the meaning or interpretation of.the tag values. > > It's mentioned in the section 4.2 that no well known tag values will be defined by this document. > Since in the mailing list there is a discussion about possibility of having well known tag value assigned by IANA. This document should clarify (based on WG consensus) if admin tags can be assigned by IANA in future documents or not. And if the answer is yes, a suitable range should be set to avoid conflict. Dhruv From nobody Wed Sep 3 07:32:24 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 6FF221A033C for ; Wed, 3 Sep 2014 07:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 QGor-pJC03xq for ; Wed, 3 Sep 2014 07:32:21 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D8A1A0334 for ; Wed, 3 Sep 2014 07:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8433; q=dns/txt; s=iport; t=1409754741; x=1410964341; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oMfJNw+9KQabwa7ucr8PuBGHIuORb4dG5TOGXVb0iWs=; b=OObss7V3b3jWvRa1+IVYTxhhj/exbRu5VFuJrr5d+cqmPGayAnomxJut 7u9vpXNlqnUg3Jk14j6rcH7FnXDDlXurFEBs1tzPjWEBPzQF0j2EnmsdY 4m7keh+wBSxXMVJ457Ees36tjyqU1FawVvS6UnWSmgA24eyaRDwI3dG8g I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQEAL4lB1StJssW/2dsb2JhbABZg2BXyEQKh0wBgSF3hAMBAQEDAQEBATU2CgEQCxUBAgkWCAcJAwIBAgEVHxETAQUCAQEXiB8IDb1+ARMEjmsRAVAHhEwBBJgahEOHN41ng2M7L4EPgUABAQE X-IronPort-AV: E=Sophos;i="5.04,457,1406592000"; d="scan'208";a="163924970" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Sep 2014 14:32:18 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s83EWIj2028086; Wed, 3 Sep 2014 14:32:18 GMT Message-ID: <54072672.4040401@cisco.com> Date: Wed, 03 Sep 2014 16:32:18 +0200 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: bruno.decraene@orange.com References: <53FC3FD8.1000704@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5406EE38.2010504@cisco.com> <11709_1409746188_5407050C_11709_11179_1_53C29892C857584299CBF5D05346208A071EC5F6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <54070740.4000906@cisco.com> <11232_1409752229_54071CA5_11232_18273_1_53C29892C857584299CBF5D05346208A071EC7B4@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <11232_1409752229_54071CA5_11232_18273_1_53C29892C857584299CBF5D05346208A071EC7B4@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/RPWgixmUkaKGmfrxFA0koZm3e7g Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 14:32:23 -0000 Hi Bruno, On 9/3/14 15:50 , bruno.decraene@orange.com wrote: > Hi Peter, > >> From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, September 03, 2014 2:19 PM >> >> Hi Bruno, >> >> On 9/3/14 14:09 , bruno.decraene@orange.com wrote: >>> Hi Peter, >>> >>>> From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, >>>> September 03, 2014 12:32 PM >>>> >>>> Hi Bruno, >>>> >>>> On 9/3/14 12:25 , bruno.decraene@orange.com wrote: >>>>> Hi Peter, Rob, >>>>> >>>>> +1 on Rob's comment regarding the use of admin tag for expressing >>>>> +operator policy (rather than spec/feature capability) >>>>> >>>>> 1 point in lined below >>>>> >>>>>> From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM >>>>>> >>>>>> Hi Rob, >>>>>> >>>>>> On 9/3/14 10:16 , Rob Shakir wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> On 3 Sep 2014, at 09:13, Peter Psenak wrote: >>>>>>> >>>>>>>>> As per the above, I do not think that this mechanism replaces >>>>>>>>> any >>>>>> capability, it just gives an operator a means to be more granular >>>>>> than the binary "supported"/"not supported" view that a flag >>>>>> indicating capabilities does. >>>>>>>> >>>>>>>> I understand. My point was that admin tags should not be used in >>>>>>>> cases >>>>>> where only a binary capability is signaled. >>>>>>> >>>>>>> ACK, I completely agree. Perhaps we should add something into the >>>> draft that the admin-tag should not be used for such a purpose. >>>>> >>>>>> I would certainly appreciate that. >>>>> >>>>> I agree as a general rule. Yet IMHO we should not kill this >>>>> possibility. In >>>> particular for feature allowing incremental deployment & interaction >>>> with non-compliant nodes. >>>>> One example would have been Remote LFA (RLFA): >>>>> - the PLR (FRR node) needs to be RLFA compliant. Therefore >>>>> (potential) >>>> communication between PLR regarding their capabilities can be done >>>> using IANA/implemented code point. >>>>> - the PQ node (Merge Point) does not need to be RLFA compliant. And >>>>> we >>>> should keep this property to ease incremental deployment. Therefore >>>> communication between PQ and PLR regarding PQ capabilities >> should/may >>>> be done using node tag. RLFA spec could have defined an IANA >>>> registered node tag to be used by PQ (configured by the network >>>> operator) to exclude them as PQ candidate. e.g. for PQ node not >>>> accepting T-LDP session or nodes which should not be used as PQ per >> policy. >>>> >>>> why is "IANA registered node tag" any better then IANA registered >>>> capability bit in the above case? >>> >>> We need the value to be able to be set/cleared by configuration (by the >> network operator) in order to allow for PQ node not compliant with RLFA to >> advertise it. >>> Node-admin tag clear matches this requirement. >>> I assumed that the capability bits were controlled by the software and not >> by the network operator and hence could not be used. However, I realize >> that this is an assumption that may be incorrect as I'm not familiar with OSPF >> implementations (as we are mostly using ISIS). If all OSPF implementations >> allow the network operator to control any bits (or at least the non >> allocated/supported ones) I think I agree that such bit could equally be used. >> However, after quickly reading the RFC, I'm not seeing that those bits >> MUST/SHOULD be configurable by configuration. Hence we can't really >> guaranty that any (future) implementation would allow this. >> >> RFC4970 does not pose any restrictions on setting of a capability bits in OSPF >> Router Informational Capabilities TLV. Some bits may be set based on the >> software capabilities of the originator but others may be set based on the >> configuration and willingness of the originator to perform certain >> functionality. The flexibility is there. > > Agreed that the flexibility is there in the spec. But the feature may not be implemented hence used. So if we add a text in node-admin-tag to forbid _any_ capability advertisement, I think we should also add a text to mandate the ability for the SP to configure RFC 4970 capability bits advertisement. spec can not forbid user/implementer to set a node tag and interpret it in any possible way on the receiving router. What the draft should spell though is that for advertising binary capabilities RI Capabilities TLV SHOULD be a preferred solution and why. Regarding the RFC 4970, I don't believe there is any new requirement, current spec allows you to do what you are asking for. thanks, Peter > > Thanks, > Bruno > >> >> thanks, >> Peter >> >>> >>> Thanks, >>> Bruno >>>> thanks, >>>> Peter >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Bruno >>>>> >>>>>> >>>>>> thanks, >>>>>> Peter >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> r. >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>>> >>>> >> __________________________________________________________ >>>> ____________ >>>>> ___________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le >>>>> detruire ainsi que les >>>> pieces jointes. Les messages electroniques etant susceptibles >>>> d'alteration, Orange decline toute responsabilite si ce message a ete >>>> altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not >>>>> be >>>> distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender >>>>> and delete >>>> this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that >>>>> have been >>>> modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> . >>>>> >>> >>> >>> >> __________________________________________________________ >> ____________ >>> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les >> pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be >> distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete >> this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >>> Thank you. >>> >>> . >>> > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > From nobody Wed Sep 3 07:46: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 6F50C1A049E for ; Wed, 3 Sep 2014 07:46:47 -0700 (PDT) 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 bYjH7b8sqLBC for ; Wed, 3 Sep 2014 07:46:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1F11A03C2 for ; Wed, 3 Sep 2014 07:45:56 -0700 (PDT) Received: from hannes-mba.local (193.110.55.12) by DM2PR05MB448.namprd05.prod.outlook.com (10.141.104.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 14:45:54 +0000 Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id B9C622B09E4; Wed, 3 Sep 2014 16:45:43 +0200 (CEST) Date: Wed, 3 Sep 2014 16:45:43 +0200 From: Hannes Gredler To: Dhruv Dhody Message-ID: <20140903144543.GC45836@juniper.net> References: <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: DB4PR06CA0038.eurprd06.prod.outlook.com (25.160.40.166) To DM2PR05MB448.namprd05.prod.outlook.com (10.141.104.152) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 032334F434 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(199003)(189002)(24454002)(83072002)(85852003)(92726001)(77982001)(92566001)(86362001)(107046002)(4396001)(101416001)(83322001)(93886004)(99396002)(97756001)(90102001)(230783001)(21056001)(23726002)(87976001)(76482001)(81342001)(106356001)(79102001)(85306004)(74502001)(77096002)(50466002)(46406003)(31966008)(50986999)(54356999)(105586002)(95666004)(46102001)(81542001)(76176999)(102836001)(64706001)(36756003)(20776003)(47776003)(19580395003)(74662001)(76506005)(80022001)(66066001)(83506001)(33656002)(110136001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB448; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/-0DAcdQdGOcuxkloDNRSAxhXsdU Cc: "ospf@ietf.org" Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag 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 Sep 2014 14:46:47 -0000 hi dhruv, On Wed, Sep 03, 2014 at 07:39:58PM +0530, Dhruv Dhody wrote: | Hi Shraddha, | | Thanks for your reply, snipping to the open point... | | > Also, it should be stated | > - if are more than one instance of this TLV in RI LSA are allowed. | > | > More than one instance of the TLV can be added in same RI-LSA or in a multiple instance as defined | > In draft-acee-ospf-rfc4970bis-00.txt | > | Okay, text may be added to reflect this. | | > (2) It should be explicitly stated that - No IANA registry is required to store the meaning or interpretation of.the tag values. | > | > It's mentioned in the section 4.2 that no well known tag values will be defined by this document. | > | Since in the mailing list there is a discussion about possibility of | having well known tag value assigned by IANA. This document should | clarify (based on WG consensus) if admin tags can be assigned by IANA | in future documents or not. And if the answer is yes, a suitable range | should be set to avoid conflict. i have no concerns with that - however peter seems in favor of using CAP Bits for well-known applications; would be interesting to hear others' opinion on that. /hannes From nobody Wed Sep 3 08:41: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 78ABB1A03ED for ; Wed, 3 Sep 2014 08:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] autolearn=no 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 OOyZjo5FA5wG for ; Wed, 3 Sep 2014 08:41:25 -0700 (PDT) Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id E914C1A0466 for ; Wed, 3 Sep 2014 08:41:16 -0700 (PDT) Received: from prz-workstation.zeta2.ch (108-228-12-76.lightspeed.sntcca.sbcglobal.net [108.228.12.76]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPSA id F289812953; Wed, 3 Sep 2014 17:41:04 +0200 (CEST) Message-ID: <5407368B.2050304@zeta2.ch> Date: Wed, 03 Sep 2014 08:40:59 -0700 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hannes Gredler References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <5404E67E.6050407@zeta2.ch> <20140902082342.GB39341@juniper.net> In-Reply-To: <20140902082342.GB39341@juniper.net> X-TagToolbar-Keys: D20140903084059313 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: F289812953.AA1F3 X-MailScanner: Found to be clean X-MailScanner-From: prz@zeta2.ch Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ZFNjJPGi-Rc_V-ZEDFAamHkcVKs Cc: ospf@ietf.org Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt 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 Sep 2014 15:41:28 -0000 On 09/02/2014 01:23 AM, Hannes Gredler wrote: > hi tony, Fuehrt' Di' Hannes ;-) > > requiring send-side ordering is certainly intended well, > but that in itself does not guarantee ordered delivery > at the receiving end :-/. I think I pointed that out already below. full ack. > > IOW in case you have an application that needs both > the 1) prefix-LSA and the 2) extended-prefix-LSA you need > to have the logic that checks presence of 1) > at the receiving end anyway. > > rather than doing things on the send-side let me suggest > to check if you have got your act together during > route-computation time. (this is a bit akin to > IS-IS fragment zero handling - ala - if frag zero > is not present then all non-zero > frag content has to be disregarded). That is required anyway, the ordering was meant as suggestion for implementors but given what Peter/Acee write (extented can be sent without the normal LSA, this makes no sense apparently). --- tony From nobody Wed Sep 3 09:13: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 1CC121A035D for ; Wed, 3 Sep 2014 09:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982] autolearn=no 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 RQ-kKD7ijCtV for ; Wed, 3 Sep 2014 09:13:48 -0700 (PDT) Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2A1A8A68 for ; Wed, 3 Sep 2014 09:13:38 -0700 (PDT) Received: from prz-workstation.zeta2.ch (108-228-12-76.lightspeed.sntcca.sbcglobal.net [108.228.12.76]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPSA id 28E8312953; Wed, 3 Sep 2014 18:13:18 +0200 (CEST) Message-ID: <54073E17.2090407@zeta2.ch> Date: Wed, 03 Sep 2014 09:13:11 -0700 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Acee Lindem (acee)" References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com> <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> In-Reply-To: <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> X-TagToolbar-Keys: D20140903091311476 Content-Type: multipart/alternative; boundary="------------010708060606020607000709" X-MailScanner-ID: 28E8312953.AC9D8 X-MailScanner: Found to be clean X-MailScanner-From: prz@zeta2.ch Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/d7u7xg6pScvP8Q2mq9PJ0ok24Lc Cc: "ospf@ietf.org" Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt 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 Sep 2014 16:13:53 -0000 This is a multi-part message in MIME format. --------------010708060606020607000709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hey Acee, >>> b) section 2. >>> >>> It may be well writing a sentence or two what should happen if an OSPFv2 >>> Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11 >>> changes) and what should happen if the same prefix appears in two >>> different flooding scopes with different information (ignore prefix in >>> both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it >>> open may lead to different treatement per router and surprising effects >> as far as the information in the two LSAs are the same, having the prefix in two LSAs with different flooding scopes is not a problem - happens today with regular LSAs.) The problem would be if the content of TLVs associated with the prefix is controversial, in which case it would be a defect on the originator side. > This is another case where the segment routing mapping server requirement makes this more complicated. I think the guidance for the case should be to give preference to the information in the LSA with area flooding scope. agree. preferring area (or in extreme case link scope ?) is simplest resolution of the issue. Agree with Acee here. It's also wise to add 'if the same extended prefix TLV (i.e. for same prefix) is seen twice in same opaque LSA only use the first and force people to put all sub-tlvs into a single tlv. > > >>> It may be also helpful to add that if an opaque extended is present but >>> the prefix (of the according type) is not in the standard LSAs, such >>> information must be disregarded. >> no, that is a valid case. One may want to advertise some extended prefix attributes without advertising the prefix's reachability. Here I think the draft may benefit from some clearer writing. Even an experienced OSPF reader is lead to assume that original LSA must be present to use the extended. "OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with advertised prefixes or links." That's strongly suggestive of "you advertise normal LSA and then you use opaque to 'extend' it" . Extended extends and is not independent from original stuff in normal use of English idiom. On top, if you start to advertise opaques & people start to compute reachability or distance based on opaques (unless you specificall state in this draft that it _cannot_ be used for that purpose, i.e. opaque influences reachability or computed metric) and you can have routers in the area that do not support opaques, an additional text is needed saying "never compute through routers without opaques using information in opaques that influences reachability or metrics". Actually, it's worse since if a router without opaques forwards through a router advertising opaques influencing metrics (for sake or simplicity), you cannot start using opaques to keep on forwarding. In case that all doesn't parse, I can do a simple looping example. >> >>> c) section 2.1 >>> >>>> Multiple OSPF Extended Prefix >>>> TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but >>>> all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA >>>> MUST have the same flooding scope. >>> may be misleading. Since they are in a opaque, the flooding scope is >>> controlled by opaque. If the type-5 vs. type-3 is meant than 'flooding >>> scope' must be disassociated between 'opaque flooidng scope' and >>> 'route-type flooding scope [as in we don't flood type-1 across ABRs]' ? >> LSA can only have single flooding scope, so all information inside LSA is limited to that flooding scope. That is what was meant by the above texts. > Actually, I had considered removing this statement when I separated the generic protocol extensions from the SR specific draft. OK, I still don't understand 'WHICH flooding scope', the type-3 vs. type-5 one or the 'opaque flodding scope one'. I think you mean 'all prefixes in the same opaque must have the same OSPF-route-type [0+unevens]' but the text is really hard to parse here. Acee, you mean remove the restriction ? I see how some implementations may benefit from cramming all type-3 into the same opaque but I would also suggest to not restrict this and remove the text. > > >>> >>> d) >>> I think it may be a valid suggestion to implementors that (for every >>> version) the according LSA SHOULD be flooded _before_ the opaque LSA >>> is flooded (which can be tad tricky [but doable] if the opaque carries a >>> bunch of those]). Yes, with reordering of flooding etc. it's not a >>> guarantee for anything but a good practice to give the protocol a chance >>> to distribute the referent (LSA) before distributing any references >>> (opaques) and additionally, will make sure that LSAs which are far more >>> important normally get out the box before opaques. >> as I said, not flooding regular LSA, only extended LSA is a valid case. > In any case, an application using extended attributes will need to be triggered by the extended prefix/link attribute LSAs. The advertising router may originate one or both of them independently. I will try to capture this disjointness in a paragraph. > yes, and again, I think 'extended' is an ill chosen name maybe if that's the intention of the draft. BTW, what is the plan if all the TLVs blow out the MTU of the opaque ? I'm missing something ? RFC5250 is not describing how the instance (they call it Opaque ID) is supposed to be generated (it references appendix A referencing section 7 which has nothing in it about this). I'm divining the instance allows to have multiple opaques of the same type which leads to bunch interesting discussions * what happens when the MTU gets blown & TLVs are shifted into next 'fragment' in ISIS speak [with all the restrictions how the TLVs can migrate between fragments, ISIS guys suffered this one [as did PNNI] @ length & will surely lend a helping hand in such a case]. * what happens if the same extended prefix TLV shows up twice in two different opaques of same type ? You use the one that is in lower opaque ID ? All nit-picking based on ample scar tissue with TLV based protocols in real deployments. thanks --- tony --------------010708060606020607000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hey Acee, 
b) section 2.

It may be well writing a sentence or two what should happen if an OSPFv2
Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11
changes) and what should happen if the same prefix appears in two
different flooding scopes with different information (ignore prefix in
both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it
open may lead to different treatement per router and surprising effects

as far as the information in the two LSAs are the same, having the prefix in two LSAs with different flooding scopes is not a problem - happens today with regular LSAs.) The problem would be if the content of TLVs associated with the prefix is controversial, in which case it would be a defect on the originator side.

This is another case where the segment routing mapping server requirement makes this more complicated. I think the guidance for the case should be to give preference to the information in the LSA with area flooding scope.
agree.  preferring area (or in extreme case link scope ?) is simplest resolution of the issue. Agree with Acee here. 

It's also wise to add 'if the same extended prefix TLV (i.e. for same prefix) is seen twice in same opaque LSA only use the first and force people to put all sub-tlvs into a single tlv. 




        

          
It may be also helpful to add that if an opaque extended is present but
the prefix (of the according type) is not in the standard LSAs, such
information must be disregarded.


        

        
no, that is a valid case. One may want to advertise some extended prefix attributes without advertising the prefix's reachability.

      

    

    Here I think the draft may benefit from some clearer writing. Even
    an experienced OSPF reader is lead to assume that original LSA must
    be present to use the extended. 

    

    "OSPFv2 requires functional extension beyond what can readily be
    done
    
 with the fixed-format Link
      State Advertisements (LSAs) as described

    
 in RFC 2328 [OSPFV2]. This
      document defines OSPF opaque LSAs based

    
 on Type-Length-Value (TLV)
      tuples that can be used to associate

    additional attributes with advertised prefixes or links."

    

    That's strongly suggestive of "you advertise normal LSA and then you
    use opaque to 'extend' it" . Extended extends and is not independent
    from original stuff in normal use of English idiom. 

    

    On top, if you start to advertise opaques & people start to
    compute reachability or distance based on opaques (unless you
    specificall state in this draft that it _cannot_ be used for that
    purpose, i.e. opaque influences reachability or computed metric) 
    and you can have routers in the area that do not support opaques, 
    an additional text is needed saying  "never compute through routers
    without opaques using information in opaques that influences
    reachability or metrics". Actually, it's worse since if a router
    without opaques forwards through a router advertising opaques
    influencing metrics (for sake or simplicity), you cannot start using
    opaques to keep on forwarding.  In case that all doesn't parse, I
    can do a simple looping example. 

    

    

    

      

        



        

          
c) section 2.1



          

            
Multiple OSPF Extended Prefix
TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but
all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA
MUST have the same flooding scope.


          

          
may be misleading. Since they are in a opaque, the flooding scope is
controlled by opaque. If  the type-5 vs. type-3 is meant than 'flooding
scope' must be disassociated between 'opaque flooidng scope' and
'route-type flooding scope [as in we don't flood type-1 across ABRs]'  ?


        

        
LSA can only have single flooding scope, so all information inside LSA is limited to that flooding scope. That is what was meant by the above texts.


      

      
Actually, I had considered removing this statement when I separated the generic protocol extensions from the SR specific draft. 

    

    

    OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
    type-5 one or the 'opaque flodding scope one'.  I think you mean
    'all prefixes in the same opaque must have the same OSPF-route-type
    [0+unevens]'  but the text is really hard to parse here.  

    

    Acee, you mean remove the restriction ?  I see how some
    implementations may benefit from cramming all type-3 into the same
    opaque but I would also suggest to not restrict this and remove the
    text. 

    

      




      

        

        

          

d)
I think it may be a valid suggestion to implementors that (for every
version) the  according  LSA  SHOULD be flooded _before_ the opaque LSA
is flooded (which can be tad tricky [but doable] if the opaque carries a
bunch of those]).  Yes, with reordering of flooding etc. it's not a
guarantee for anything but a good practice to give the protocol a chance
to distribute the referent (LSA) before distributing any references
(opaques) and additionally, will make sure that  LSAs which are far more
important normally get out the box before opaques.


        

        
as I said, not flooding regular LSA, only extended LSA is a valid case.


      

      
In any case, an application using extended attributes will need to be triggered by the extended prefix/link attribute LSAs.  The advertising router may originate one or both of them independently. I will try to capture this disjointness in a paragraph. 



    

    

    yes, and again, I think 'extended' is an ill chosen name maybe if
    that's the intention of the draft.

    

    BTW, what is the plan if all the TLVs blow out the MTU of the opaque
    ?  I'm missing something ?   RFC5250 is not describing how the
    instance (they call it Opaque ID) is supposed to be generated (it
    references appendix A referencing section 7 which has nothing in it
    about this).  I'm divining the instance allows to have multiple
    opaques of the same type which leads to bunch interesting
    discussions

         * what happens when the MTU gets blown & TLVs are shifted
    into next 'fragment' in ISIS speak [with all the restrictions how
    the TLVs can migrate between fragments, ISIS guys suffered this one
    [as did PNNI] @ length & will surely lend a helping hand in such
    a case]. 

         * what happens if the same extended prefix TLV shows up twice
    in two different opaques of same type ?  You use the one that is in
    lower opaque ID ? 

    

    All nit-picking based on ample scar tissue with TLV based protocols
    in real deployments. 

    

    thanks 

    

    --- tony 

    

    

  


--------------010708060606020607000709--


From nobody Wed Sep  3 12:23:44 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 476051A0650 for ; Wed,  3 Sep 2014 12:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 MVfHganZeTCf for ; Wed,  3 Sep 2014 12:23:40 -0700 (PDT)
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 515C71A064D for ; Wed,  3 Sep 2014 12:23:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2568; q=dns/txt; s=iport; t=1409772220; x=1410981820; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2eck55husW0WEW123y0A51hY5ecCS16YS6Vv32wuIrQ=; b=ieKrnpUvpsv4m0PTPiqQ1iiX+Sd573cOkgNUj+ASskUw/l4ZS+Us33h9 +VTcR4bxj22WxP9qa64kKe6vn/dTjr3FxqBvZhXd9Q6zlOFv0xnFmkJL0 b41x18Zq9Lph1ERUasCeGkfMpiMFUX5ER35KZY0+mHPs7GAs0XT25Jqu4 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQEAOppB1StJssW/2dsb2JhbABZg2BXyEUKh0wBgSN3hAMBAQEDAQEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGINggNvx8BEwSPTQeETAEEnF2VHoNjOy+CTwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,459,1406592000"; d="scan'208";a="164836841"
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; 03 Sep 2014 19:23:37 +0000
Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s83JNZ4U020442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Sep 2014 19:23:36 GMT
Message-ID: <54076AB7.5080106@cisco.com>
Date: Wed, 03 Sep 2014 21:23:35 +0200
From: Anton Smirnov 
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Hannes Gredler 
References:   <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com>  <20140903144543.GC45836@juniper.net>
In-Reply-To: <20140903144543.GC45836@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-User: asmirnov
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/lel_CxUqJUEy_uZQ3SK1zBRMKQQ
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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 Sep 2014 19:23:42 -0000

    Hi Hannes,

 > would be interesting to hear others' opinion on that.

    My opinion is that in future defining a new well-known admin tag 
value is by definition requires new IETF draft/RFC. But if new draft is 
being written then it is cleaner to define data container which suits 
the new feature best, be it new capability bit, new RI LSA TLV, new data 
in another LSA or combination of above.
    Problems with defining well-known tag values:
- It will be necessary to sacrifice a range of tag values for future 
well-known tags
- It will be necessary to define behavior of implementation receiving 
unknown tag

    Benefits of defining well-known tags vs. defining in future new TLVs 
for features as needed:
- Well, I can't think of any.

So my opinion is that there should be no well-known tags (neither in WG 
nor internally to an implementation) and tag values should have meaning 
in the context of policy of a particular network. Very much like there 
are no well-known values for tags attached to external LSAs.

Anton


On 09/03/2014 04:45 PM, Hannes Gredler wrote:
> hi dhruv,
>
> On Wed, Sep 03, 2014 at 07:39:58PM +0530, Dhruv Dhody wrote:
> | Hi Shraddha,
> |
> | Thanks for your reply, snipping to the open point...
> |
> | > Also, it should be stated
> | > - if are more than one instance of this TLV in RI LSA are allowed.
> | >
> | > More than one instance of the TLV can be added in same RI-LSA or in a multiple instance as defined
> | >                        In  draft-acee-ospf-rfc4970bis-00.txt
> | >
> | Okay, text may be added to reflect this.
> |
> | > (2) It should be explicitly stated that - No IANA registry is required to store the meaning or interpretation of.the tag values.
> | >
> | >  It's mentioned in the section 4.2 that no well known  tag values will be defined by this document.
> | >
> | Since in the mailing list there is a discussion about possibility of
> | having well known tag value assigned by IANA. This document should
> | clarify (based on WG consensus) if admin tags can be assigned by IANA
> | in future documents or not. And if the answer is yes, a suitable range
> | should be set to avoid conflict.
>
> i have no concerns with that -
> however peter seems in favor of using CAP Bits for well-known applications;
>
> would be interesting to hear others' opinion on that.
>
> /hannes
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>


From nobody Wed Sep  3 20:43:08 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 05F0A1A6ED8 for ; Wed,  3 Sep 2014 20:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level: 
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Msg7m_Jpms_6 for ; Wed,  3 Sep 2014 20:43:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5671A6F73 for ; Wed,  3 Sep 2014 20:43:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJA98063; Thu, 04 Sep 2014 03:43:03 +0000 (GMT)
Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Sep 2014 04:43:02 +0100
Received: from szxeml556-mbs.china.huawei.com ([169.254.4.229]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 11:40:50 +0800
From: Dhruv Dhody 
To: Hannes Gredler , Dhruv Dhody 
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvomviAgAXeGICAAID8AIAACf2AgAFeCFA=
Date: Thu, 4 Sep 2014 03:40:48 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B865DC895@szxeml556-mbs.china.huawei.com>
References:   <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com>  <20140903144543.GC45836@juniper.net>
In-Reply-To: <20140903144543.GC45836@juniper.net>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.146.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/uxakbM1tt_D8Dv2MSt7WzpWyik4
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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 Sep 2014 03:43:07 -0000

Hi Hannes,=20

> |
> | > (2) It should be explicitly stated that - No IANA registry is require=
d to
> store the meaning or interpretation of.the tag values.
> | >
> | >  It's mentioned in the section 4.2 that no well known  tag
> values will be defined by this document.
> | >
> | Since in the mailing list there is a discussion about possibility of
> | having well known tag value assigned by IANA. This document should
> | clarify (based on WG consensus) if admin tags can be assigned by IANA
> | in future documents or not. And if the answer is yes, a suitable range
> | should be set to avoid conflict.
>=20
> i have no concerns with that -
> however peter seems in favor of using CAP Bits for well-known application=
s;
>=20
> would be interesting to hear others' opinion on that.

FWIW I prefer CAP bits as well and yes! it would interesting to hear from o=
thers!=20

Dhruv


From nobody Thu Sep  4 00:24: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 3ECA91A6EE4 for ; Thu,  4 Sep 2014 00:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 snEbLAX17y_y for ; Thu,  4 Sep 2014 00:24:25 -0700 (PDT)
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 EF2441A2130 for ; Thu,  4 Sep 2014 00:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7807; q=dns/txt; s=iport; t=1409815465; x=1411025065; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tCi8FznZFk0ge0d/50bFrijQ49Pm60e3pHThvmrmtJw=; b=N2oBLgzc7BY/bATnw344tb9skFwq5PjcIpvKNKGp6+5PLowhBA5bILtx 0nJGKQDMEVAMm+pj3dL0KxZRSUPE6OLFBH1OPGpHMULqQcUnsuSTbsDtc vnXM7eNMx6yS4LvNz0GQQNOHKm5BEdkVp5WUUb49Nu42ofVCwm6HkksVu Y=;
X-IronPort-AV: E=Sophos;i="5.04,464,1406592000"; d="scan'208";a="160681988"
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; 04 Sep 2014 07:24:23 +0000
Received: from [10.55.51.206] (ams-ppsenak-87113.cisco.com [10.55.51.206]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s847OMpg022161; Thu, 4 Sep 2014 07:24:23 GMT
Message-ID: <540813A7.60802@cisco.com>
Date: Thu, 04 Sep 2014 09:24:23 +0200
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: "A. Przygienda" , "Acee Lindem (acee)" 
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch>
In-Reply-To: <54073E17.2090407@zeta2.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/nk0H1JginxrQrzBjoT0iRkh3YS8
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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 Sep 2014 07:24:27 -0000

Hi Tony,

please see inline:

On 9/3/14 18:13 , A. Przygienda wrote:
> Hey Acee,
>>>> b) section 2.
>>>>
>>>> It may be well writing a sentence or two what should happen if an OSPFv2
>>>> Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11
>>>> changes) and what should happen if the same prefix appears in two
>>>> different flooding scopes with different information (ignore prefix in
>>>> both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it
>>>> open may lead to different treatement per router and surprising effects
>>> as far as the information in the two LSAs are the same, having the prefix in two LSAs with different flooding scopes is not a problem - happens today with regular LSAs.) The problem would be if the content of TLVs associated with the prefix is controversial, in which case it would be a defect on the originator side.
>> This is another case where the segment routing mapping server requirement makes this more complicated. I think the guidance for the case should be to give preference to the information in the LSA with area flooding scope.
> agree.  preferring area (or in extreme case link scope ?) is simplest
> resolution of the issue. Agree with Acee here.
>
> It's also wise to add 'if the same extended prefix TLV (i.e. for same
> prefix) is seen twice in same opaque LSA only use the first and force
> people to put all sub-tlvs into a single tlv.

it's kind of obvious, but we can add a text to be sure.

>>
>>
>>>> It may be also helpful to add that if an opaque extended is present but
>>>> the prefix (of the according type) is not in the standard LSAs, such
>>>> information must be disregarded.
>>> no, that is a valid case. One may want to advertise some extended prefix attributes without advertising the prefix's reachability.
> Here I think the draft may benefit from some clearer writing. Even an
> experienced OSPF reader is lead to assume that original LSA must be
> present to use the extended.
>
> "OSPFv2 requires functional extension beyond what can readily be done
> with the fixed-format Link State Advertisements (LSAs) as described
> in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
> on Type-Length-Value (TLV) tuples that can be used to associate
> additional attributes with advertised prefixes or links."
>
> That's strongly suggestive of "you advertise normal LSA and then you use
> opaque to 'extend' it" . Extended extends and is not independent from
> original stuff in normal use of English idiom.

because existing LSA are not extensible, any additional link/prefix 
attributes must be advertised in a separate LSAs. We called it 
"extended", but it does not mean that existence of the extended LSA 
require existence of the base LSA. I had a text in the original SR draft 
around that, we can add it here too.


>
> On top, if you start to advertise opaques & people start to compute
> reachability or distance based on opaques (unless you specificall state
> in this draft that it _cannot_ be used for that purpose, i.e. opaque
> influences reachability or computed metric) and you can have routers in
> the area that do not support opaques, an additional text is needed
> saying  "never compute through routers without opaques using information
> in opaques that influences reachability or metrics". Actually, it's
> worse since if a router without opaques forwards through a router
> advertising opaques influencing metrics (for sake or simplicity), you
> cannot start using opaques to keep on forwarding.  In case that all
> doesn't parse, I can do a simple looping example.

we are not advertising any metrics in the extended LSAs, so I do not see 
why we would have to deal with that case here. If one day someone wants 
to do that, then it would have to be covered in a separate draft and we 
would deal with it at that time.

>
>
>>>
>>>> c) section 2.1
>>>>
>>>>> Multiple OSPF Extended Prefix
>>>>> TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but
>>>>> all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA
>>>>> MUST have the same flooding scope.
>>>> may be misleading. Since they are in a opaque, the flooding scope is
>>>> controlled by opaque. If  the type-5 vs. type-3 is meant than 'flooding
>>>> scope' must be disassociated between 'opaque flooidng scope' and
>>>> 'route-type flooding scope [as in we don't flood type-1 across ABRs]'  ?
>>> LSA can only have single flooding scope, so all information inside LSA is limited to that flooding scope. That is what was meant by the above texts.
>> Actually, I had considered removing this statement when I separated the generic protocol extensions from the SR specific draft.
>
> OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
> type-5 one or the 'opaque flodding scope one'.  I think you mean 'all
> prefixes in the same opaque must have the same OSPF-route-type
> [0+unevens]'  but the text is really hard to parse here.
>
> Acee, you mean remove the restriction ?  I see how some implementations
> may benefit from cramming all type-3 into the same opaque but I would
> also suggest to not restrict this and remove the text.

the restriction can not be removed. All the Extended Prefix TLVs that 
you put in a singe Extended Prefix LSA will only use a flooding scope of 
the Extended LSA itself.

>>
>>
>>>>
>>>> d)
>>>> I think it may be a valid suggestion to implementors that (for every
>>>> version) the  according  LSA  SHOULD be flooded _before_ the opaque LSA
>>>> is flooded (which can be tad tricky [but doable] if the opaque carries a
>>>> bunch of those]).  Yes, with reordering of flooding etc. it's not a
>>>> guarantee for anything but a good practice to give the protocol a chance
>>>> to distribute the referent (LSA) before distributing any references
>>>> (opaques) and additionally, will make sure that  LSAs which are far more
>>>> important normally get out the box before opaques.
>>> as I said, not flooding regular LSA, only extended LSA is a valid case.
>> In any case, an application using extended attributes will need to be triggered by the extended prefix/link attribute LSAs.  The advertising router may originate one or both of them independently. I will try to capture this disjointness in a paragraph.
>>
>
> yes, and again, I think 'extended' is an ill chosen name maybe if that's
> the intention of the draft.
>
> BTW, what is the plan if all the TLVs blow out the MTU of the opaque ?

you can generate many Extended Prefix or Extended Link LSAs, so there is 
no issue.

> I'm missing something ?   RFC5250 is not describing how the instance
> (they call it Opaque ID) is supposed to be generated (it references
> appendix A referencing section 7 which has nothing in it about this).
> I'm divining the instance allows to have multiple opaques of the same
> type which leads to bunch interesting discussions
>       * what happens when the MTU gets blown & TLVs are shifted into
> next 'fragment' in ISIS speak [with all the restrictions how the TLVs
> can migrate between fragments, ISIS guys suffered this one [as did PNNI]
> @ length & will surely lend a helping hand in such a case].

TLVs can come and go and move from one Extended Opaque LSA to the other. 
Implementation needs to track these changes and deal with them.


>       * what happens if the same extended prefix TLV shows up twice in
> two different opaques of same type ?  You use the one that is in lower
> opaque ID ?

I would call it a bug on the originator side.

thanks,
Peter

>
> All nit-picking based on ample scar tissue with TLV based protocols in
> real deployments.
>
> thanks
>
> --- tony
>
>


From nobody Thu Sep  4 11:19: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 8A7071A010A for ; Thu,  4 Sep 2014 11:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 DbkP1OKq9oGQ for ; Thu,  4 Sep 2014 11:19:07 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB281A0125 for ; Thu,  4 Sep 2014 11:19:06 -0700 (PDT)
Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 4 Sep 2014 18:18:58 +0000
Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.219]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.219]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 18:18:57 +0000
From: Shraddha Hegde 
To: Dhruv Dhody , Hannes Gredler ,  Dhruv Dhody 
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvpIRSAgAXa+UCAAIQbAIAACf2AgADYjgCAAPQqEA==
Date: Thu, 4 Sep 2014 18:18:56 +0000
Message-ID: 
References:   <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com>  <20140903144543.GC45836@juniper.net> <23CE718903A838468A8B325B80962F9B865DC895@szxeml556-mbs.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B865DC895@szxeml556-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [116.197.184.18]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 0324C2C0E2
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(51704005)(377454003)(199003)(189002)(21056001)(87936001)(83072002)(99396002)(76482001)(76176999)(93886004)(74316001)(50986999)(33646002)(77982001)(106116001)(85852003)(2656002)(1941001)(95666004)(46102001)(20776003)(85306004)(99286002)(76576001)(90102001)(101416001)(74662001)(66066001)(81542001)(54356999)(80022001)(31966008)(4396001)(108616004)(19580405001)(81342001)(79102001)(19580395003)(15975445006)(64706001)(77096002)(86362001)(83322001)(74502001)(105586002)(230783001)(92566001)(106356001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB437; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; 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/wA3sGPWf-39yRGvcF-Z_WOo7TfI
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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 Sep 2014 18:19:09 -0000

My preference would be to use Capability bits/new TLV for well known applic=
ations and
Using node-tags for config/policy driven generic applications.=20

That said there is no-harm in reserving a range of tags in this document an=
d mentioning it's for "future" use.

Rgds
shraddha

-----Original Message-----
From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: Thursday, September 04, 2014 9:11 AM
To: Hannes Gredler; Dhruv Dhody
Cc: ospf@ietf.org
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi Hannes,=20

> |
> | > (2) It should be explicitly stated that - No IANA registry is=20
> | > required to
> store the meaning or interpretation of.the tag values.
> | >
> | >  It's mentioned in the section 4.2 that no well known =20
> | > tag
> values will be defined by this document.
> | >
> | Since in the mailing list there is a discussion about possibility of=20
> | having well known tag value assigned by IANA. This document should=20
> | clarify (based on WG consensus) if admin tags can be assigned by=20
> | IANA in future documents or not. And if the answer is yes, a=20
> | suitable range should be set to avoid conflict.
>=20
> i have no concerns with that -
> however peter seems in favor of using CAP Bits for well-known=20
> applications;
>=20
> would be interesting to hear others' opinion on that.

FWIW I prefer CAP bits as well and yes! it would interesting to hear from o=
thers!=20

Dhruv

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


From nobody Thu Sep  4 12:03:19 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 243871A02ED for ; Thu,  4 Sep 2014 12:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level: 
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] autolearn=no
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 zJ7iawvbpUXM for ; Thu,  4 Sep 2014 12:03:13 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 087521A02FE for ; Thu,  4 Sep 2014 12:03:12 -0700 (PDT)
Received: from prz-workstation.zeta2.ch (108-228-12-76.lightspeed.sntcca.sbcglobal.net [108.228.12.76]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPSA id C4D24129DC for ; Thu,  4 Sep 2014 21:02:59 +0200 (CEST)
Message-ID: <5408B75E.4040106@zeta2.ch>
Date: Thu, 04 Sep 2014 12:02:54 -0700
From: "A. Przygienda" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: ospf@ietf.org
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com>
In-Reply-To: <540813A7.60802@cisco.com>
X-TagToolbar-Keys: D20140904120254450
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: C4D24129DC.AC2A3
X-MailScanner: Found to be clean
X-MailScanner-From: prz@zeta2.ch
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ccDq60JXhJhsCda-43gf2w__AOE
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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 Sep 2014 19:03:18 -0000

On 09/04/2014 12:24 AM, Peter Psenak wrote:
> Hi Tony,
>
> please see inline:

Hey Peter, same

>
> On 9/3/14 18:13 , A. Przygienda wrote:
>>
>>
>> It's also wise to add 'if the same extended prefix TLV (i.e. for same
>> prefix) is seen twice in same opaque LSA only use the first and force
>> people to put all sub-tlvs into a single tlv.
>
> it's kind of obvious, but we can add a text to be sure.

As I see it, the purpose of an RFC is to assure interoperability. If
there are two
interpretations available of the same packet that will make two
solutions not interoperable, 
the standard has to mandate the correct one.

>
>>
>> "OSPFv2 requires functional extension beyond what can readily be done
>> with the fixed-format Link State Advertisements (LSAs) as described
>> in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
>> on Type-Length-Value (TLV) tuples that can be used to associate
>> additional attributes with advertised prefixes or links."
>>
>> That's strongly suggestive of "you advertise normal LSA and then you use
>> opaque to 'extend' it" . Extended extends and is not independent from
>> original stuff in normal use of English idiom.
>
> because existing LSA are not extensible, any additional link/prefix
> attributes must be advertised in a separate LSAs. We called it
> "extended", but it does not mean that existence of the extended LSA
> require existence of the base LSA. I had a text in the original SR
> draft around that, we can add it here too.

yepp, once it spelled out, it's obvious but the first conclusion one
jumps to is that they are inter-dependent otherwise.

>
>
>> .,..
>> the area that do not support opaques, an additional text is needed
>> saying  "never compute through routers without opaques using information
>> in opaques that influences reachability or metrics". Actually, it's
>> worse since if a router without opaques forwards through a router
>> advertising opaques influencing metrics (for sake or simplicity), you
>> cannot start using opaques to keep on forwarding.  In case that all
>> doesn't parse, I can do a simple looping example.
>
> we are not advertising any metrics in the extended LSAs, so I do not
> see why we would have to deal with that case here. If one day someone
> wants to do that, then it would have to be covered in a separate draft
> and we would deal with it at that time.

agreed here. you're correct. That would be overspecification in this draft

>
>> OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
>> type-5 one or the 'opaque flodding scope one'.  I think you mean 'all
>> prefixes in the same opaque must have the same OSPF-route-type
>> [0+unevens]'  but the text is really hard to parse here.
>>
>> Acee, you mean remove the restriction ?  I see how some implementations
>> may benefit from cramming all type-3 into the same opaque but I would
>> also suggest to not restrict this and remove the text.
>
> the restriction can not be removed. All the Extended Prefix TLVs that
> you put in a singe Extended Prefix LSA will only use a flooding scope
> of the Extended LSA itself.

I still think it's not clear what the original paragraph means.

>
>> yes, and again, I think 'extended' is an ill chosen name maybe if that's
>> the intention of the draft.
>>
>> BTW, what is the plan if all the TLVs blow out the MTU of the opaque ?
>
> you can generate many Extended Prefix or Extended Link LSAs, so there
> is no issue.

ack

>
>> I'm missing something ?   RFC5250 is not describing how the instance
>> (they call it Opaque ID) is supposed to be generated (it references
>> appendix A referencing section 7 which has nothing in it about this).
>> I'm divining the instance allows to have multiple opaques of the same
>> type which leads to bunch interesting discussions
>>       * what happens when the MTU gets blown & TLVs are shifted into
>> next 'fragment' in ISIS speak [with all the restrictions how the TLVs
>> can migrate between fragments, ISIS guys suffered this one [as did PNNI]
>> @ length & will surely lend a helping hand in such a case].
>
> TLVs can come and go and move from one Extended Opaque LSA to the
> other. Implementation needs to track these changes and deal with them.

I would let the ISIS guys chime in here. They have tons experience with
TLVs sliding fragments and what kind of implementation/operation pain
that can cause.

>
>
>>       * what happens if the same extended prefix TLV shows up twice in
>> two different opaques of same type ?  You use the one that is in lower
>> opaque ID ?
>
> I would call it a bug on the originator side.

yes, but still, the draft should mandate what the desired behavior is @
this point in time otherwise some will use the lower ID, some higher and
some none of the above & the implementations will not interop ?

--- tony


From nobody Thu Sep  4 14:23: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 A92C61A01AA for ; Thu,  4 Sep 2014 14:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 PUJaOqMHIhJv for ; Thu,  4 Sep 2014 14:23:14 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224D31A01A5 for ; Thu,  4 Sep 2014 14:23:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2172; q=dns/txt; s=iport; t=1409865794; x=1411075394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TqQOiOyflR/B3EWcSN7ubJQFr4MlCOcOxzAolEK0wPs=; b=BhILHxvEopHafDCFazQd1AoLxp5HcwKOVoc2Z3vspFaTYtYGNfwSh3GL s+bSXEaqcv3GcYAAtgiZe26pUFRTC2l0QiCA9AqZKPrsnxM+YqJOLjEKs QhvJLqa2uQUx9aCPZkrp2alyfLmqAfD48cjrZFv1TKXG5/QY3smKinr+S E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkoFAGXXCFStJV2Z/2dsb2JhbABZgw1TVwTIHgqHTAGBChZ3hAMBAQEEAQEBawsMBAIBCBEEAQEoBycLFAkIAgQBDQWIQg29PQETBI8iKwcGhEYFiniGRosulSKDYWyBSIEHAQEB
X-IronPort-AV: E=Sophos;i="5.04,468,1406592000"; d="scan'208";a="352700194"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 04 Sep 2014 21:23:13 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s84LND4O017977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 21:23:13 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 16:23:13 -0500
From: "Acee Lindem (acee)" 
To: Shraddha Hegde , Dhruv Dhody , Hannes Gredler , Dhruv Dhody 
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvpdOaAgAXeGICAAID8AIAACf2AgADYjgCAAPVZAP//8GyA
Date: Thu, 4 Sep 2014 21:23:12 +0000
Message-ID: 
References:   <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com>  <20140903144543.GC45836@juniper.net> <23CE718903A838468A8B325B80962F9B865DC895@szxeml556-mbs.china.huawei.com> 
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.196]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <38F73DE3F498434593884698D87D1CC0@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/hZaaCxtDcXLSHSeBlgvlWBiQowY
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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 Sep 2014 21:23:15 -0000

Speaking as WG member:

 I agree with using capability bits for whether or not a OSPF router can
support something and administrative tags for policy. I don=B9t think we
should have well-known tags and am not really even in favor of reserving a
range just in case we need them.
Thanks,
Acee=20

On 9/4/14, 2:18 PM, "Shraddha Hegde"  wrote:

>My preference would be to use Capability bits/new TLV for well known
>applications and
>Using node-tags for config/policy driven generic applications.
>
>That said there is no-harm in reserving a range of tags in this document
>and mentioning it's for "future" use.
>
>Rgds
>shraddha
>
>-----Original Message-----
>From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Dhruv Dhody
>Sent: Thursday, September 04, 2014 9:11 AM
>To: Hannes Gredler; Dhruv Dhody
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] Poll for WG adoption of
>draft-hegde-ospf-node-admin-tag
>
>Hi Hannes,=20
>
>> |
>> | > (2) It should be explicitly stated that - No IANA registry is
>> | > required to
>> store the meaning or interpretation of.the tag values.
>> | >
>> | >  It's mentioned in the section 4.2 that no well known
>> | > tag
>> values will be defined by this document.
>> | >
>> | Since in the mailing list there is a discussion about possibility of
>> | having well known tag value assigned by IANA. This document should
>> | clarify (based on WG consensus) if admin tags can be assigned by
>> | IANA in future documents or not. And if the answer is yes, a
>> | suitable range should be set to avoid conflict.
>>=20
>> i have no concerns with that -
>> however peter seems in favor of using CAP Bits for well-known
>> applications;
>>=20
>> would be interesting to hear others' opinion on that.
>
>FWIW I prefer CAP bits as well and yes! it would interesting to hear from
>others!=20
>
>Dhruv
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf


From nobody Thu Sep  4 20:48: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 EAC551A03C9 for ; Thu,  4 Sep 2014 20:48:10 -0700 (PDT)
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 O9_Fa2DnCcly for ; Thu,  4 Sep 2014 20:48:08 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CAA1A03D3 for ; Thu,  4 Sep 2014 20:48:08 -0700 (PDT)
Received: by mail-ig0-f177.google.com with SMTP id r10so2357156igi.4 for ; Thu, 04 Sep 2014 20:48:07 -0700 (PDT)
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=7V2FcBx89offNxRIPM5vr9xLnR6pfcJBba8cY1KcZnc=; b=V7iw0m4tanhLCBkOQyGKjqaI30FCO47Lg90PeyKZ37uEuHDihw0sjqUUjuiWtWa8Si 9/AyvZev5tR9fVIvHFOzqMPdSPqK8oZoW9wTmdMJV4F/d23uZzybZGoP8lGnSD6Xvosi oaZ/9M++eeG3B29vrVxauHGZ7iIYgBTJQpOQT2BGaYZYLQFwuBHfQWiU+ZzgOUgfI6Sn rWpN93sdHZw2CrS6Ana8k65Oyg3Xi0QBkrH1qHbJKzHC417kOWlExKf5F7p31X15i9hw NP6vBYOpms0ZpGVU3C/OwGQq87P3UEDx+dylEaoqAwt6RW4tIs3xuUhvCDPvT8oBCfPe 2Hzg==
MIME-Version: 1.0
X-Received: by 10.43.167.196 with SMTP id nf4mr11153157icc.22.1409888887433; Thu, 04 Sep 2014 20:48:07 -0700 (PDT)
Received: by 10.50.89.232 with HTTP; Thu, 4 Sep 2014 20:48:07 -0700 (PDT)
Received: by 10.50.89.232 with HTTP; Thu, 4 Sep 2014 20:48:07 -0700 (PDT)
In-Reply-To: 
References:   <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com>  <20140903144543.GC45836@juniper.net> <23CE718903A838468A8B325B80962F9B865DC895@szxeml556-mbs.china.huawei.com>  
Date: Fri, 5 Sep 2014 09:18:07 +0530
Message-ID: 
From: Dhruv Dhody 
To: "Acee Lindem (acee)" 
Content-Type: multipart/alternative; boundary=001a11c2d6764efef70502495668
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/xbl1eP7SZ1TJfNHhk1nbSlHKIqM
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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 Sep 2014 03:48:11 -0000

--001a11c2d6764efef70502495668
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree with Acee, it is cleaner to keep admin tags only for private use,
never to be allocated by IANA.

Dhruv
 On Sep 5, 2014 5:23 AM, "Acee Lindem (acee)"  wrote:

> Speaking as WG member:
>
>  I agree with using capability bits for whether or not a OSPF router can
> support something and administrative tags for policy. I don=C2=B9t think =
we
> should have well-known tags and am not really even in favor of reserving =
a
> range just in case we need them.
> Thanks,
> Acee
>
> On 9/4/14, 2:18 PM, "Shraddha Hegde"  wrote:
>
> >My preference would be to use Capability bits/new TLV for well known
> >applications and
> >Using node-tags for config/policy driven generic applications.
> >
> >That said there is no-harm in reserving a range of tags in this document
> >and mentioning it's for "future" use.
> >
> >Rgds
> >shraddha
> >
> >-----Original Message-----
> >From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Dhruv Dhody
> >Sent: Thursday, September 04, 2014 9:11 AM
> >To: Hannes Gredler; Dhruv Dhody
> >Cc: ospf@ietf.org
> >Subject: Re: [OSPF] Poll for WG adoption of
> >draft-hegde-ospf-node-admin-tag
> >
> >Hi Hannes,
> >
> >> |
> >> | > (2) It should be explicitly stated that - No IANA registry is
> >> | > required to
> >> store the meaning or interpretation of.the tag values.
> >> | >
> >> | >  It's mentioned in the section 4.2 that no well known
> >> | > tag
> >> values will be defined by this document.
> >> | >
> >> | Since in the mailing list there is a discussion about possibility of
> >> | having well known tag value assigned by IANA. This document should
> >> | clarify (based on WG consensus) if admin tags can be assigned by
> >> | IANA in future documents or not. And if the answer is yes, a
> >> | suitable range should be set to avoid conflict.
> >>
> >> i have no concerns with that -
> >> however peter seems in favor of using CAP Bits for well-known
> >> applications;
> >>
> >> would be interesting to hear others' opinion on that.
> >
> >FWIW I prefer CAP bits as well and yes! it would interesting to hear fro=
m
> >others!
> >
> >Dhruv
> >
> >_______________________________________________
> >OSPF mailing list
> >OSPF@ietf.org
> >https://www.ietf.org/mailman/listinfo/ospf
> >
> >_______________________________________________
> >OSPF mailing list
> >OSPF@ietf.org
> >https://www.ietf.org/mailman/listinfo/ospf
>
>

--001a11c2d6764efef70502495668
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I agree with Acee, it is cleaner to keep admin tags only for=
 private use, never to be allocated by IANA.=C2=A0 


Dhruv




On Sep 5, 2014 5:23 AM, "Acee Lindem (acee)=
" <acee@cisco.com> wrote:<=
br type=3D"attribution">
Speaking as WG membe=
r:



=C2=A0I agree with using capability bits for whether or not a OSPF router c=
an

support something and administrative tags for policy. I don=C2=B9t think we=


should have well-known tags and am not really even in favor of reserving a<=
br>
range just in case we need them.

Thanks,

Acee



On 9/4/14, 2:18 PM, "Shraddha Hegde" <shraddha@juniper.net> wrote:



>My preference would be to use Capability bits/new TLV for well known
>applications and

>Using node-tags for config/policy driven generic applications.

>

>That said there is no-harm in reserving a range of tags in this documen=
t

>and mentioning it's for "future" use.

>

>Rgds

>shraddha

>

>-----Original Message-----

>From: OSPF [mailto:ospf-bounce=
s@ietf.org] On Behalf Of Dhruv Dhody

>Sent: Thursday, September 04, 2014 9:11 AM

>To: Hannes Gredler; Dhruv Dhody

>Cc: ospf@ietf.org

>Subject: Re: [OSPF] Poll for WG adoption of

>draft-hegde-ospf-node-admin-tag

>

>Hi Hannes,

>

>> |

>> | > (2) It should be explicitly stated that - No IANA registry =
is

>> | > required to

>> store the meaning or interpretation of.the tag values.

>> | >

>> | > <Shraddha> It's mentioned in the section 4.2 that=
 no well known

>> | > tag

>> values will be defined by this document.

>> | >

>> | Since in the mailing list there is a discussion about possibilit=
y of

>> | having well known tag value assigned by IANA. This document shou=
ld

>> | clarify (based on WG consensus) if admin tags can be assigned by=


>> | IANA in future documents or not. And if the answer is yes, a

>> | suitable range should be set to avoid conflict.

>>

>> i have no concerns with that -

>> however peter seems in favor of using CAP Bits for well-known

>> applications;

>>

>> would be interesting to hear others' opinion on that.

>

>FWIW I prefer CAP bits as well and yes! it would interesting to hear fr=
om

>others!

>

>Dhruv

>

>_______________________________________________

>OSPF mailing list

>OSPF@ietf.org

>https://www.ietf.org/mailman/listinfo/ospf

>

>_______________________________________________

>OSPF mailing list

>OSPF@ietf.org

>https://www.ietf.org/mailman/listinfo/ospf






--001a11c2d6764efef70502495668--


From nobody Thu Sep  4 23:38: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 57A621A045D for ; Thu,  4 Sep 2014 23:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level: 
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 vQ51kEnn8t-E for ; Thu,  4 Sep 2014 23:38:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A9F1A0460 for ; Thu,  4 Sep 2014 23:38:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJC09640; Fri, 05 Sep 2014 06:38:07 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 5 Sep 2014 07:37:21 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 5 Sep 2014 14:37:16 +0800
From: Xuxiaohu 
To: Dhruv Dhody , "Acee Lindem (acee)" 
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPxFE0GbQFoOONyUaUf4QhM2C3GJvuccKAgACA+wCAAAn+gIAA2I4AgAD1WQCAADN8AIAAa4uAgAC1QRA=
Date: Fri, 5 Sep 2014 06:37:16 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AD6CF@NKGEML512-MBS.china.huawei.com>
References:   <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com>  <20140903144543.GC45836@juniper.net> <23CE718903A838468A8B325B80962F9B865DC895@szxeml556-mbs.china.huawei.com>   
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AD6CFNKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/loftG4M90Xjxkj-nspBMFXcUkVo
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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 Sep 2014 06:38:12 -0000

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AD6CFNKGEML512MBSchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzENCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCkZyb206IE9TUEYgW21haWx0bzpvc3BmLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaHJ1diBEaG9keQ0KU2VudDogRnJpZGF5LCBT
ZXB0ZW1iZXIgMDUsIDIwMTQgMTE6NDggQU0NClRvOiBBY2VlIExpbmRlbSAoYWNlZSkNCkNjOiBv
c3BmQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09TUEZdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIG9m
IGRyYWZ0LWhlZ2RlLW9zcGYtbm9kZS1hZG1pbi10YWcNCg0KDQpJIGFncmVlIHdpdGggQWNlZSwg
aXQgaXMgY2xlYW5lciB0byBrZWVwIGFkbWluIHRhZ3Mgb25seSBmb3IgcHJpdmF0ZSB1c2UsIG5l
dmVyIHRvIGJlIGFsbG9jYXRlZCBieSBJQU5BLg0KDQpEaHJ1dg0KT24gU2VwIDUsIDIwMTQgNToy
MyBBTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNp
c2NvLmNvbT4+IHdyb3RlOg0KU3BlYWtpbmcgYXMgV0cgbWVtYmVyOg0KDQogSSBhZ3JlZSB3aXRo
IHVzaW5nIGNhcGFiaWxpdHkgYml0cyBmb3Igd2hldGhlciBvciBub3QgYSBPU1BGIHJvdXRlciBj
YW4NCnN1cHBvcnQgc29tZXRoaW5nIGFuZCBhZG1pbmlzdHJhdGl2ZSB0YWdzIGZvciBwb2xpY3ku
IEkgZG9uwrl0IHRoaW5rIHdlDQpzaG91bGQgaGF2ZSB3ZWxsLWtub3duIHRhZ3MgYW5kIGFtIG5v
dCByZWFsbHkgZXZlbiBpbiBmYXZvciBvZiByZXNlcnZpbmcgYQ0KcmFuZ2UganVzdCBpbiBjYXNl
IHdlIG5lZWQgdGhlbS4NClRoYW5rcywNCkFjZWUNCg0KT24gOS80LzE0LCAyOjE4IFBNLCAiU2hy
YWRkaGEgSGVnZGUiIDxzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hyYWRkaGFAanVuaXBl
ci5uZXQ+PiB3cm90ZToNCg0KPk15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gdXNlIENhcGFiaWxp
dHkgYml0cy9uZXcgVExWIGZvciB3ZWxsIGtub3duDQo+YXBwbGljYXRpb25zIGFuZA0KPlVzaW5n
IG5vZGUtdGFncyBmb3IgY29uZmlnL3BvbGljeSBkcml2ZW4gZ2VuZXJpYyBhcHBsaWNhdGlvbnMu
DQo+DQo+VGhhdCBzYWlkIHRoZXJlIGlzIG5vLWhhcm0gaW4gcmVzZXJ2aW5nIGEgcmFuZ2Ugb2Yg
dGFncyBpbiB0aGlzIGRvY3VtZW50DQo+YW5kIG1lbnRpb25pbmcgaXQncyBmb3IgImZ1dHVyZSIg
dXNlLg0KPg0KPlJnZHMNCj5zaHJhZGRoYQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+RnJvbTogT1NQRiBbbWFpbHRvOm9zcGYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b3NwZi1i
b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERocnV2IERob2R5DQo+U2VudDogVGh1cnNk
YXksIFNlcHRlbWJlciAwNCwgMjAxNCA5OjExIEFNDQo+VG86IEhhbm5lcyBHcmVkbGVyOyBEaHJ1
diBEaG9keQ0KPkNjOiBvc3BmQGlldGYub3JnPG1haWx0bzpvc3BmQGlldGYub3JnPg0KPlN1Ympl
Y3Q6IFJlOiBbT1NQRl0gUG9sbCBmb3IgV0cgYWRvcHRpb24gb2YNCj5kcmFmdC1oZWdkZS1vc3Bm
LW5vZGUtYWRtaW4tdGFnDQo+DQo+SGkgSGFubmVzLA0KPg0KPj4gfA0KPj4gfCA+ICgyKSBJdCBz
aG91bGQgYmUgZXhwbGljaXRseSBzdGF0ZWQgdGhhdCAtIE5vIElBTkEgcmVnaXN0cnkgaXMNCj4+
IHwgPiByZXF1aXJlZCB0bw0KPj4gc3RvcmUgdGhlIG1lYW5pbmcgb3IgaW50ZXJwcmV0YXRpb24g
b2YudGhlIHRhZyB2YWx1ZXMuDQo+PiB8ID4NCj4+IHwgPiA8U2hyYWRkaGE+IEl0J3MgbWVudGlv
bmVkIGluIHRoZSBzZWN0aW9uIDQuMiB0aGF0IG5vIHdlbGwga25vd24NCj4+IHwgPiB0YWcNCj4+
IHZhbHVlcyB3aWxsIGJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudC4NCj4+IHwgPg0KPj4gfCBT
aW5jZSBpbiB0aGUgbWFpbGluZyBsaXN0IHRoZXJlIGlzIGEgZGlzY3Vzc2lvbiBhYm91dCBwb3Nz
aWJpbGl0eSBvZg0KPj4gfCBoYXZpbmcgd2VsbCBrbm93biB0YWcgdmFsdWUgYXNzaWduZWQgYnkg
SUFOQS4gVGhpcyBkb2N1bWVudCBzaG91bGQNCj4+IHwgY2xhcmlmeSAoYmFzZWQgb24gV0cgY29u
c2Vuc3VzKSBpZiBhZG1pbiB0YWdzIGNhbiBiZSBhc3NpZ25lZCBieQ0KPj4gfCBJQU5BIGluIGZ1
dHVyZSBkb2N1bWVudHMgb3Igbm90LiBBbmQgaWYgdGhlIGFuc3dlciBpcyB5ZXMsIGENCj4+IHwg
c3VpdGFibGUgcmFuZ2Ugc2hvdWxkIGJlIHNldCB0byBhdm9pZCBjb25mbGljdC4NCj4+DQo+PiBp
IGhhdmUgbm8gY29uY2VybnMgd2l0aCB0aGF0IC0NCj4+IGhvd2V2ZXIgcGV0ZXIgc2VlbXMgaW4g
ZmF2b3Igb2YgdXNpbmcgQ0FQIEJpdHMgZm9yIHdlbGwta25vd24NCj4+IGFwcGxpY2F0aW9uczsN
Cj4+DQo+PiB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBoZWFyIG90aGVycycgb3BpbmlvbiBvbiB0
aGF0Lg0KPg0KPkZXSVcgSSBwcmVmZXIgQ0FQIGJpdHMgYXMgd2VsbCBhbmQgeWVzISBpdCB3b3Vs
ZCBpbnRlcmVzdGluZyB0byBoZWFyIGZyb20NCj5vdGhlcnMhDQo+DQo+RGhydXYNCj4NCj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk9TUEYgbWFpbGlu
ZyBsaXN0DQo+T1NQRkBpZXRmLm9yZzxtYWlsdG86T1NQRkBpZXRmLm9yZz4NCj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCj4NCj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk9TUEYgbWFpbGluZyBsaXN0DQo+T1NQRkBp
ZXRmLm9yZzxtYWlsdG86T1NQRkBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29zcGYNCg==

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AD6CFNKGEML512MBSchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz
cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw
dCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOzE8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlhb2h1PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+IE9TUEYgW21haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh
bGYgT2YgPC9iPkRocnV2IERob2R5PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVy
IDA1LCAyMDE0IDExOjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBBY2VlIExpbmRlbSAoYWNlZSk8YnI+
DQo8Yj5DYzo8L2I+IG9zcGZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPU1BG
XSBQb2xsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1oZWdkZS1vc3BmLW5vZGUtYWRtaW4tdGFn
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48
c3BhbiBsYW5nPSJFTi1VUyI+SSBhZ3JlZSB3aXRoIEFjZWUsIGl0IGlzIGNsZWFuZXIgdG8ga2Vl
cCBhZG1pbiB0YWdzIG9ubHkgZm9yIHByaXZhdGUgdXNlLCBuZXZlciB0byBiZSBhbGxvY2F0ZWQg
YnkgSUFOQS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO
LVVTIj5EaHJ1djxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gU2VwIDUsIDIwMTQgNToyMyBBTSwgJnF1b3Q7QWNl
ZSBMaW5kZW0gKGFjZWUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20i
PmFjZWVAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+U3BlYWtpbmcgYXMgV0cgbWVtYmVyOjxicj4NCjxicj4NCiZuYnNwO0kgYWdyZWUg
d2l0aCB1c2luZyBjYXBhYmlsaXR5IGJpdHMgZm9yIHdoZXRoZXIgb3Igbm90IGEgT1NQRiByb3V0
ZXIgY2FuPGJyPg0Kc3VwcG9ydCBzb21ldGhpbmcgYW5kIGFkbWluaXN0cmF0aXZlIHRhZ3MgZm9y
IHBvbGljeS4gSSBkb27CuXQgdGhpbmsgd2U8YnI+DQpzaG91bGQgaGF2ZSB3ZWxsLWtub3duIHRh
Z3MgYW5kIGFtIG5vdCByZWFsbHkgZXZlbiBpbiBmYXZvciBvZiByZXNlcnZpbmcgYTxicj4NCnJh
bmdlIGp1c3QgaW4gY2FzZSB3ZSBuZWVkIHRoZW0uPGJyPg0KVGhhbmtzLDxicj4NCkFjZWU8YnI+
DQo8YnI+DQpPbiA5LzQvMTQsIDI6MTggUE0sICZxdW90O1NocmFkZGhhIEhlZ2RlJnF1b3Q7ICZs
dDs8YSBocmVmPSJtYWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQiPnNocmFkZGhhQGp1bmlwZXIu
bmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O015IHByZWZlcmVuY2Ugd291bGQgYmUg
dG8gdXNlIENhcGFiaWxpdHkgYml0cy9uZXcgVExWIGZvciB3ZWxsIGtub3duPGJyPg0KJmd0O2Fw
cGxpY2F0aW9ucyBhbmQ8YnI+DQomZ3Q7VXNpbmcgbm9kZS10YWdzIGZvciBjb25maWcvcG9saWN5
IGRyaXZlbiBnZW5lcmljIGFwcGxpY2F0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYXQgc2Fp
ZCB0aGVyZSBpcyBuby1oYXJtIGluIHJlc2VydmluZyBhIHJhbmdlIG9mIHRhZ3MgaW4gdGhpcyBk
b2N1bWVudDxicj4NCiZndDthbmQgbWVudGlvbmluZyBpdCdzIGZvciAmcXVvdDtmdXR1cmUmcXVv
dDsgdXNlLjxicj4NCiZndDs8YnI+DQomZ3Q7Umdkczxicj4NCiZndDtzaHJhZGRoYTxicj4NCiZn
dDs8YnI+DQomZ3Q7LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7RnJvbTogT1NQ
RiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmciPm9zcGYtYm91
bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEaHJ1diBEaG9keTxicj4NCiZndDtTZW50
OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA0LCAyMDE0IDk6MTEgQU08YnI+DQomZ3Q7VG86IEhhbm5l
cyBHcmVkbGVyOyBEaHJ1diBEaG9keTxicj4NCiZndDtDYzogPGEgaHJlZj0ibWFpbHRvOm9zcGZA
aWV0Zi5vcmciPm9zcGZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0O1N1YmplY3Q6IFJlOiBbT1NQRl0g
UG9sbCBmb3IgV0cgYWRvcHRpb24gb2Y8YnI+DQomZ3Q7ZHJhZnQtaGVnZGUtb3NwZi1ub2RlLWFk
bWluLXRhZzxicj4NCiZndDs8YnI+DQomZ3Q7SGkgSGFubmVzLDxicj4NCiZndDs8YnI+DQomZ3Q7
Jmd0OyB8PGJyPg0KJmd0OyZndDsgfCAmZ3Q7ICgyKSBJdCBzaG91bGQgYmUgZXhwbGljaXRseSBz
dGF0ZWQgdGhhdCAtIE5vIElBTkEgcmVnaXN0cnkgaXM8YnI+DQomZ3Q7Jmd0OyB8ICZndDsgcmVx
dWlyZWQgdG88YnI+DQomZ3Q7Jmd0OyBzdG9yZSB0aGUgbWVhbmluZyBvciBpbnRlcnByZXRhdGlv
biBvZi50aGUgdGFnIHZhbHVlcy48YnI+DQomZ3Q7Jmd0OyB8ICZndDs8YnI+DQomZ3Q7Jmd0OyB8
ICZndDsgJmx0O1NocmFkZGhhJmd0OyBJdCdzIG1lbnRpb25lZCBpbiB0aGUgc2VjdGlvbiA0LjIg
dGhhdCBubyB3ZWxsIGtub3duPGJyPg0KJmd0OyZndDsgfCAmZ3Q7IHRhZzxicj4NCiZndDsmZ3Q7
IHZhbHVlcyB3aWxsIGJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudC48YnI+DQomZ3Q7Jmd0OyB8
ICZndDs8YnI+DQomZ3Q7Jmd0OyB8IFNpbmNlIGluIHRoZSBtYWlsaW5nIGxpc3QgdGhlcmUgaXMg
YSBkaXNjdXNzaW9uIGFib3V0IHBvc3NpYmlsaXR5IG9mPGJyPg0KJmd0OyZndDsgfCBoYXZpbmcg
d2VsbCBrbm93biB0YWcgdmFsdWUgYXNzaWduZWQgYnkgSUFOQS4gVGhpcyBkb2N1bWVudCBzaG91
bGQ8YnI+DQomZ3Q7Jmd0OyB8IGNsYXJpZnkgKGJhc2VkIG9uIFdHIGNvbnNlbnN1cykgaWYgYWRt
aW4gdGFncyBjYW4gYmUgYXNzaWduZWQgYnk8YnI+DQomZ3Q7Jmd0OyB8IElBTkEgaW4gZnV0dXJl
IGRvY3VtZW50cyBvciBub3QuIEFuZCBpZiB0aGUgYW5zd2VyIGlzIHllcywgYTxicj4NCiZndDsm
Z3Q7IHwgc3VpdGFibGUgcmFuZ2Ugc2hvdWxkIGJlIHNldCB0byBhdm9pZCBjb25mbGljdC48YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IGkgaGF2ZSBubyBjb25jZXJucyB3aXRoIHRoYXQgLTxi
cj4NCiZndDsmZ3Q7IGhvd2V2ZXIgcGV0ZXIgc2VlbXMgaW4gZmF2b3Igb2YgdXNpbmcgQ0FQIEJp
dHMgZm9yIHdlbGwta25vd248YnI+DQomZ3Q7Jmd0OyBhcHBsaWNhdGlvbnM7PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBoZWFyIG90aGVycycgb3Bp
bmlvbiBvbiB0aGF0Ljxicj4NCiZndDs8YnI+DQomZ3Q7RldJVyBJIHByZWZlciBDQVAgYml0cyBh
cyB3ZWxsIGFuZCB5ZXMhIGl0IHdvdWxkIGludGVyZXN0aW5nIHRvIGhlYXIgZnJvbTxicj4NCiZn
dDtvdGhlcnMhPGJyPg0KJmd0Ozxicj4NCiZndDtEaHJ1djxicj4NCiZndDs8YnI+DQomZ3Q7X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7T1NQ
RiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJlZj0ibWFpbHRvOk9TUEZAaWV0Zi5vcmciPk9T
UEZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb3NwZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb3NwZjwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0O19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O09TUEYgbWFpbGlu
ZyBsaXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0bzpPU1BGQGlldGYub3JnIj5PU1BGQGlldGYu
b3JnPC9hPjxicj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29zcGYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29zcGY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AD6CFNKGEML512MBSchi_--


From nobody Fri Sep  5 00:11: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 A7C2A1A047B for ; Fri,  5 Sep 2014 00:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 eIO-0IkExioy for ; Fri,  5 Sep 2014 00:10:59 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22FB1A046A for ; Fri,  5 Sep 2014 00:10:58 -0700 (PDT)
Received: from hannes-mba.local (193.110.55.12) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 5 Sep 2014 07:10:57 +0000
Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 9732C2B9039; Fri,  5 Sep 2014 09:10:38 +0200 (CEST)
Date: Fri, 5 Sep 2014 09:10:38 +0200
From: Hannes Gredler 
To: Peter Psenak 
Message-ID: <20140905071038.GA50935@juniper.net>
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <540813A7.60802@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Originating-IP: [193.110.55.12]
X-ClientProxiedBy: AM3PR05CA036.eurprd05.prod.outlook.com (10.141.192.46) To BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;
X-Forefront-PRVS: 0325F6C77B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(189002)(199003)(24454002)(479174003)(77096002)(76506005)(97756001)(81342001)(4396001)(23726002)(102836001)(90102001)(36756003)(230783001)(33656002)(95666004)(83506001)(46406003)(79102001)(21056001)(107046002)(50986999)(76176999)(99396002)(74502001)(74662001)(77982001)(110136001)(50466002)(76482001)(46102001)(85306004)(93886004)(105586002)(80022001)(64706001)(20776003)(47776003)(66066001)(83322001)(106356001)(81542001)(83072002)(85852003)(92566001)(31966008)(101416001)(54356999)(92726001)(87976001)(86362001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB434; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/tNyhmU5jML1bEl45cKFOkoJAFso
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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 Sep 2014 07:11:01 -0000

On Thu, Sep 04, 2014 at 09:24:23AM +0200, Peter Psenak wrote:
| Hi Tony,
| 
| please see inline:
| 
| On 9/3/14 18:13 , A. Przygienda wrote:
| >Hey Acee,
| >>>>b) section 2.
| >>>>
| >>>>It may be well writing a sentence or two what should happen if an OSPFv2
| >>>>Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11
| >>>>changes) and what should happen if the same prefix appears in two
| >>>>different flooding scopes with different information (ignore prefix in
| >>>>both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it
| >>>>open may lead to different treatement per router and surprising effects
| >>>as far as the information in the two LSAs are the same, having the prefix in two LSAs with different flooding scopes is not a problem - happens today with regular LSAs.) The problem would be if the content of TLVs associated with the prefix is controversial, in which case it would be a defect on the originator side.
| >>This is another case where the segment routing mapping server requirement makes this more complicated. I think the guidance for the case should be to give preference to the information in the LSA with area flooding scope.
| >agree.  preferring area (or in extreme case link scope ?) is simplest
| >resolution of the issue. Agree with Acee here.
| >
| >It's also wise to add 'if the same extended prefix TLV (i.e. for same
| >prefix) is seen twice in same opaque LSA only use the first and force
| >people to put all sub-tlvs into a single tlv.
| 
| it's kind of obvious, but we can add a text to be sure.
  ^^^^^^^^^^^^^^^^^^^^

only for the educated eye :-)


From nobody Fri Sep  5 01:34:20 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 3D22A1A0674 for ; Fri,  5 Sep 2014 01:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 9ftMmr_kN8dG for ; Fri,  5 Sep 2014 01:34:14 -0700 (PDT)
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 9BE241A0075 for ; Fri,  5 Sep 2014 01:34:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5777; q=dns/txt; s=iport; t=1409906048; x=1411115648; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=sa+XQf8gQHo3096l6o2rIuI+d7d02NxTZfuyeULSbJw=; b=i9AMkvHCtzMat21SBrY9We0JtA1aVQAVZHbjZ7nUx5pKr2TuocgqzRUd q1kHIibFBolxfBX4mW2UDR1toKRk0Zrx4tut1sjNifBJuJeY4cmmFWKMS eEDG0n7jhT9U0I+RDvTxHzEqwKtIM9sB/GRrqSoRpjmCwj4lE9z7hxlrl o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsEAHJ0CVStJssW/2dsb2JhbABZg2BXyEsKh0wBgSB3hAMBAQEEAQEBNTYJARELGAkWDwkDAgECARUnCQYBDAYCAQEXiCcNvWsBEwSPVIRMAQScbIc5jWmCG4FIOy+CTwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,471,1406592000"; d="scan'208";a="166802005"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Sep 2014 08:34:06 +0000
Received: from [10.55.51.206] (ams-ppsenak-87113.cisco.com [10.55.51.206]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s858Y4de003037; Fri, 5 Sep 2014 08:34:06 GMT
Message-ID: <5409757C.7040600@cisco.com>
Date: Fri, 05 Sep 2014 10:34:04 +0200
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: "A. Przygienda" , ospf@ietf.org
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com> <5408B75E.4040106@zeta2.ch>
In-Reply-To: <5408B75E.4040106@zeta2.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0g8xm5icxlhG3BeZe5OmV3-b5M0
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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 Sep 2014 08:34:18 -0000

Hi Tony,

please see inline:

On 9/4/14 21:02 , A. Przygienda wrote:
> On 09/04/2014 12:24 AM, Peter Psenak wrote:
>> Hi Tony,
>>
>> please see inline:
>
> Hey Peter, same
>
>>
>> On 9/3/14 18:13 , A. Przygienda wrote:
>>>
>>>
>>> It's also wise to add 'if the same extended prefix TLV (i.e. for same
>>> prefix) is seen twice in same opaque LSA only use the first and force
>>> people to put all sub-tlvs into a single tlv.
>>
>> it's kind of obvious, but we can add a text to be sure.
>
> As I see it, the purpose of an RFC is to assure interoperability. If
> there are two
> interpretations available of the same packet that will make two
> solutions not interoperable,
> the standard has to mandate the correct one.

ok, we will add a text to make it clear.

>
>>
>>>
>>> "OSPFv2 requires functional extension beyond what can readily be done
>>> with the fixed-format Link State Advertisements (LSAs) as described
>>> in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
>>> on Type-Length-Value (TLV) tuples that can be used to associate
>>> additional attributes with advertised prefixes or links."
>>>
>>> That's strongly suggestive of "you advertise normal LSA and then you use
>>> opaque to 'extend' it" . Extended extends and is not independent from
>>> original stuff in normal use of English idiom.
>>
>> because existing LSA are not extensible, any additional link/prefix
>> attributes must be advertised in a separate LSAs. We called it
>> "extended", but it does not mean that existence of the extended LSA
>> require existence of the base LSA. I had a text in the original SR
>> draft around that, we can add it here too.
>
> yepp, once it spelled out, it's obvious but the first conclusion one
> jumps to is that they are inter-dependent otherwise.

ok, we will add a text to clarify.

>
>>
>>
>>> .,..
>>> the area that do not support opaques, an additional text is needed
>>> saying  "never compute through routers without opaques using information
>>> in opaques that influences reachability or metrics". Actually, it's
>>> worse since if a router without opaques forwards through a router
>>> advertising opaques influencing metrics (for sake or simplicity), you
>>> cannot start using opaques to keep on forwarding.  In case that all
>>> doesn't parse, I can do a simple looping example.
>>
>> we are not advertising any metrics in the extended LSAs, so I do not
>> see why we would have to deal with that case here. If one day someone
>> wants to do that, then it would have to be covered in a separate draft
>> and we would deal with it at that time.
>
> agreed here. you're correct. That would be overspecification in this draft
>
>>
>>> OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
>>> type-5 one or the 'opaque flodding scope one'.  I think you mean 'all
>>> prefixes in the same opaque must have the same OSPF-route-type
>>> [0+unevens]'  but the text is really hard to parse here.
>>>
>>> Acee, you mean remove the restriction ?  I see how some implementations
>>> may benefit from cramming all type-3 into the same opaque but I would
>>> also suggest to not restrict this and remove the text.
>>
>> the restriction can not be removed. All the Extended Prefix TLVs that
>> you put in a singe Extended Prefix LSA will only use a flooding scope
>> of the Extended LSA itself.
>
> I still think it's not clear what the original paragraph means.

prefixes can have different flooding scope. Today intra-area and 
inter-area prefixes have area flooding scope and external prefixes have 
domain wide flooding scope. You can not mix prefixes of different 
flooding scope in a single Extended Prefix LSA, because Extended Prefix 
LSA can only have a single flooding scope.

>
>>
>>> yes, and again, I think 'extended' is an ill chosen name maybe if that's
>>> the intention of the draft.
>>>
>>> BTW, what is the plan if all the TLVs blow out the MTU of the opaque ?
>>
>> you can generate many Extended Prefix or Extended Link LSAs, so there
>> is no issue.
>
> ack
>
>>
>>> I'm missing something ?   RFC5250 is not describing how the instance
>>> (they call it Opaque ID) is supposed to be generated (it references
>>> appendix A referencing section 7 which has nothing in it about this).
>>> I'm divining the instance allows to have multiple opaques of the same
>>> type which leads to bunch interesting discussions
>>>        * what happens when the MTU gets blown & TLVs are shifted into
>>> next 'fragment' in ISIS speak [with all the restrictions how the TLVs
>>> can migrate between fragments, ISIS guys suffered this one [as did PNNI]
>>> @ length & will surely lend a helping hand in such a case].
>>
>> TLVs can come and go and move from one Extended Opaque LSA to the
>> other. Implementation needs to track these changes and deal with them.
>
> I would let the ISIS guys chime in here. They have tons experience with
> TLVs sliding fragments and what kind of implementation/operation pain
> that can cause.
>
>>
>>
>>>        * what happens if the same extended prefix TLV shows up twice in
>>> two different opaques of same type ?  You use the one that is in lower
>>> opaque ID ?
>>
>> I would call it a bug on the originator side.
>
> yes, but still, the draft should mandate what the desired behavior is @
> this point in time otherwise some will use the lower ID, some higher and
> some none of the above & the implementations will not interop ?

ok, we will add a tiebreaker there.

thanks,
Peter
>
> --- tony
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> .
>


From nobody Fri Sep  5 05:37:31 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 1B7A71A06AC for ; Fri,  5 Sep 2014 05:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 hUa-jDm8xrpk for ; Fri,  5 Sep 2014 05:37:18 -0700 (PDT)
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 CB5431A06A4 for ; Fri,  5 Sep 2014 05:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6290; q=dns/txt; s=iport; t=1409920638; x=1411130238; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YY7VuQmDXiKro39bi9yGv0r1Qf5t6pOoFYsLPAiUUgI=; b=lghOWAgqdcMyCzNsYrdAXOF2TBnBl7/tgYBLhq7B7U4alhv2Nil+xbWT p1qTRTZUgpk4p6Zs9zhVesLdqhLCDxuqCvOF2tGOF3O9zFegdI5ZqFX6l LJUgun+SwoUezQKAyIKSqZljNsx83/yT38S6nOwe9h+hwXsOajrejwnW7 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAOetCVStJV2Z/2dsb2JhbABZgw1TVwTIfgqHTAGBChZ3hAMBAQEEAQEBNzQJEgIBCBgeECcLHAkCBAESG4gnDb4bARMEj1SETAWRPosulSaCG4FGbIFIgQcBAQE
X-IronPort-AV: E=Sophos;i="5.04,472,1406592000"; d="scan'208";a="349756345"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 05 Sep 2014 12:37:17 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s85CbFrw012832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 12:37:15 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 07:37:15 -0500
From: "Acee Lindem (acee)" 
To: "Peter Psenak (ppsenak)" , "A. Przygienda" , "ospf@ietf.org" 
Thread-Topic: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
Thread-Index: AQHPtlGQNLZvkWuqU0uFf/90h1EvfZvOlLMAgB6rngCAAKUNAIAAZ/CAgAG9yoCAAP6WgIAAwyoAgADiowD///+hAA==
Date: Fri, 5 Sep 2014 12:37:15 +0000
Message-ID: 
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com> <5408B75E.4040106@zeta2.ch> <5409757C.7040600@cisco.com>
In-Reply-To: <5409757C.7040600@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/96p_rLUMkqdwADyjraRlQGYJaKw
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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 Sep 2014 12:37:21 -0000

Hi Tony, Peter,=20

I plan to update the draft next week and address some of these
clarifications.

Thanks,
Acee=20

On 9/5/14, 4:34 AM, "Peter Psenak (ppsenak)"  wrote:

>Hi Tony,
>
>please see inline:
>
>On 9/4/14 21:02 , A. Przygienda wrote:
>> On 09/04/2014 12:24 AM, Peter Psenak wrote:
>>> Hi Tony,
>>>
>>> please see inline:
>>
>> Hey Peter, same
>>
>>>
>>> On 9/3/14 18:13 , A. Przygienda wrote:
>>>>
>>>>
>>>> It's also wise to add 'if the same extended prefix TLV (i.e. for same
>>>> prefix) is seen twice in same opaque LSA only use the first and force
>>>> people to put all sub-tlvs into a single tlv.
>>>
>>> it's kind of obvious, but we can add a text to be sure.
>>
>> As I see it, the purpose of an RFC is to assure interoperability. If
>> there are two
>> interpretations available of the same packet that will make two
>> solutions not interoperable,
>> the standard has to mandate the correct one.
>
>ok, we will add a text to make it clear.
>
>>
>>>
>>>>
>>>> "OSPFv2 requires functional extension beyond what can readily be done
>>>> with the fixed-format Link State Advertisements (LSAs) as described
>>>> in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
>>>> on Type-Length-Value (TLV) tuples that can be used to associate
>>>> additional attributes with advertised prefixes or links."
>>>>
>>>> That's strongly suggestive of "you advertise normal LSA and then you
>>>>use
>>>> opaque to 'extend' it" . Extended extends and is not independent from
>>>> original stuff in normal use of English idiom.
>>>
>>> because existing LSA are not extensible, any additional link/prefix
>>> attributes must be advertised in a separate LSAs. We called it
>>> "extended", but it does not mean that existence of the extended LSA
>>> require existence of the base LSA. I had a text in the original SR
>>> draft around that, we can add it here too.
>>
>> yepp, once it spelled out, it's obvious but the first conclusion one
>> jumps to is that they are inter-dependent otherwise.
>
>ok, we will add a text to clarify.
>
>>
>>>
>>>
>>>> .,..
>>>> the area that do not support opaques, an additional text is needed
>>>> saying  "never compute through routers without opaques using
>>>>information
>>>> in opaques that influences reachability or metrics". Actually, it's
>>>> worse since if a router without opaques forwards through a router
>>>> advertising opaques influencing metrics (for sake or simplicity), you
>>>> cannot start using opaques to keep on forwarding.  In case that all
>>>> doesn't parse, I can do a simple looping example.
>>>
>>> we are not advertising any metrics in the extended LSAs, so I do not
>>> see why we would have to deal with that case here. If one day someone
>>> wants to do that, then it would have to be covered in a separate draft
>>> and we would deal with it at that time.
>>
>> agreed here. you're correct. That would be overspecification in this
>>draft
>>
>>>
>>>> OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
>>>> type-5 one or the 'opaque flodding scope one'.  I think you mean 'all
>>>> prefixes in the same opaque must have the same OSPF-route-type
>>>> [0+unevens]'  but the text is really hard to parse here.
>>>>
>>>> Acee, you mean remove the restriction ?  I see how some
>>>>implementations
>>>> may benefit from cramming all type-3 into the same opaque but I would
>>>> also suggest to not restrict this and remove the text.
>>>
>>> the restriction can not be removed. All the Extended Prefix TLVs that
>>> you put in a singe Extended Prefix LSA will only use a flooding scope
>>> of the Extended LSA itself.
>>
>> I still think it's not clear what the original paragraph means.
>
>prefixes can have different flooding scope. Today intra-area and
>inter-area prefixes have area flooding scope and external prefixes have
>domain wide flooding scope. You can not mix prefixes of different
>flooding scope in a single Extended Prefix LSA, because Extended Prefix
>LSA can only have a single flooding scope.
>
>>
>>>
>>>> yes, and again, I think 'extended' is an ill chosen name maybe if
>>>>that's
>>>> the intention of the draft.
>>>>
>>>> BTW, what is the plan if all the TLVs blow out the MTU of the opaque ?
>>>
>>> you can generate many Extended Prefix or Extended Link LSAs, so there
>>> is no issue.
>>
>> ack
>>
>>>
>>>> I'm missing something ?   RFC5250 is not describing how the instance
>>>> (they call it Opaque ID) is supposed to be generated (it references
>>>> appendix A referencing section 7 which has nothing in it about this).
>>>> I'm divining the instance allows to have multiple opaques of the same
>>>> type which leads to bunch interesting discussions
>>>>        * what happens when the MTU gets blown & TLVs are shifted into
>>>> next 'fragment' in ISIS speak [with all the restrictions how the TLVs
>>>> can migrate between fragments, ISIS guys suffered this one [as did
>>>>PNNI]
>>>> @ length & will surely lend a helping hand in such a case].
>>>
>>> TLVs can come and go and move from one Extended Opaque LSA to the
>>> other. Implementation needs to track these changes and deal with them.
>>
>> I would let the ISIS guys chime in here. They have tons experience with
>> TLVs sliding fragments and what kind of implementation/operation pain
>> that can cause.
>>
>>>
>>>
>>>>        * what happens if the same extended prefix TLV shows up twice
>>>>in
>>>> two different opaques of same type ?  You use the one that is in lower
>>>> opaque ID ?
>>>
>>> I would call it a bug on the originator side.
>>
>> yes, but still, the draft should mandate what the desired behavior is @
>> this point in time otherwise some will use the lower ID, some higher and
>> some none of the above & the implementations will not interop ?
>
>ok, we will add a tiebreaker there.
>
>thanks,
>Peter
>>
>> --- tony
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>> .
>>
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf


From nobody Fri Sep  5 09:44: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 58EF31A0AE8 for ; Fri,  5 Sep 2014 09:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 3ZqmdE9TqiQP for ; Fri,  5 Sep 2014 09:44:32 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3041A0739 for ; Fri,  5 Sep 2014 09:44:32 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-09-54099332103b
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C7.35.05330.23399045; Fri,  5 Sep 2014 12:40:50 +0200 (CEST)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 5 Sep 2014 12:44:29 -0400
From: Jeff Tantsura 
To: "Acee Lindem (acee)" , Shraddha Hegde , Dhruv Dhody , Hannes Gredler , Dhruv Dhody 
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvpZCOAgAXeF4CAAID8AIAACf2AgADYjgCAAPVZAIAAM3wAgADPEYA=
Date: Fri, 5 Sep 2014 16:44:28 +0000
Message-ID: 
References:   <60f1a1748bfc4deabe293f0b5b99633d@BY2PR05MB127.namprd05.prod.outlook.com>  <20140903144543.GC45836@juniper.net> <23CE718903A838468A8B325B80962F9B865DC895@szxeml556-mbs.china.huawei.com>  
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.3.140616
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <4F0D99D410E82247BF168BC20EA945BE@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyuXRPrK7RZM4Qg5kfpCwmv53HbNG/4gyL Rfe8n0wW/feesFm03LvHbnHj0V5mBzaPKb83snrsnHWX3aPlyFtWjyVLfjJ5XG+6yh7AGsVl k5Kak1mWWqRvl8CVsfDmC7aCGXIVk9bfZ2pg3CLbxcjJISFgInFm9y12CFtM4sK99WxdjFwc QgJHGSVeTtzBDJIQEljGKLHmShSIzSZgIPH/23EWkCIRgcOMEktWvWQBSTALKEs87lrNBmIL C3hLzGzuAYuLCPhIPDy3G2gDB5CdJDH1qA5ImEVAReLp+78sIGFeAXOJO1sCIPY+YZa49OUa K0gNp4C2xNQPqxlBbEag476fWsMEsUpc4taT+UwQRwtILNlznhnCFpV4+fgfWK+ogJ7Epynn oGqUJCYtPccK0asl8eXHPjYI21pi9rONjBC2osSU7ofggOAVEJQ4OfMJywRGiVlI1s1C0j4L SfssJO2zkLQvYGRdxchRWpxalptuZLCJERizxyTYdHcw7nlpeYhRgINRiYd3wQqOECHWxLLi ytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHRe+jhF+sT6q9LrxA+V zd5ow52XlG++2FvqUoCg9EwR41fP206JhGcahT15ZjmLj4Fz2kKzo1zTD6lvT9O/8WjN2YSV fxubFmzLm5r6a3229xSHGV7vuVet+qW75O/21illZ/64XdCXLXMs2D/3Ube76qJvGry7dRYa XWj+6xIWl9rIG82kI6TEUpyRaKjFXFScCADTuUykugIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Krf3LxZsEojEQti0j5OxGrISfhM
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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 Sep 2014 16:44:34 -0000

SGksDQoNCkkgc3VwcG9ydCBBY2Vloa9zIGNvbW1lbnRzLg0KDQpDaGVlcnMsDQpKZWZmDQoNCg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiQWNlZSBMaW5kZW0gICAoYWNl
ZSkiIDxhY2VlQGNpc2NvLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBTZXB0ZW1iZXIgNCwgMjAxNCBh
dCAyOjIzIFBNDQpUbzogU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PiwgRGhy
dXYgRGhvZHkNCjxkaHJ1di5kaG9keUBodWF3ZWkuY29tPiwgImhhbm5lc0BqdW5pcGVyLm5ldCIg
PGhhbm5lc0BqdW5pcGVyLm5ldD4sIERocnV2DQpEaG9keSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+
DQpDYzogIm9zcGZAaWV0Zi5vcmciIDxvc3BmQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPU1BG
XSBQb2xsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1oZWdkZS1vc3BmLW5vZGUtYWRtaW4tdGFn
DQoNCj5TcGVha2luZyBhcyBXRyBtZW1iZXI6DQo+DQo+IEkgYWdyZWUgd2l0aCB1c2luZyBjYXBh
YmlsaXR5IGJpdHMgZm9yIHdoZXRoZXIgb3Igbm90IGEgT1NQRiByb3V0ZXIgY2FuDQo+c3VwcG9y
dCBzb21ldGhpbmcgYW5kIGFkbWluaXN0cmF0aXZlIHRhZ3MgZm9yIHBvbGljeS4gSSBkb26p9nQg
dGhpbmsgd2UNCj5zaG91bGQgaGF2ZSB3ZWxsLWtub3duIHRhZ3MgYW5kIGFtIG5vdCByZWFsbHkg
ZXZlbiBpbiBmYXZvciBvZiByZXNlcnZpbmcgYQ0KPnJhbmdlIGp1c3QgaW4gY2FzZSB3ZSBuZWVk
IHRoZW0uDQo+VGhhbmtzLA0KPkFjZWUgDQo+DQo+T24gOS80LzE0LCAyOjE4IFBNLCAiU2hyYWRk
aGEgSGVnZGUiIDxzaHJhZGRoYUBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+DQo+Pk15IHByZWZlcmVu
Y2Ugd291bGQgYmUgdG8gdXNlIENhcGFiaWxpdHkgYml0cy9uZXcgVExWIGZvciB3ZWxsIGtub3du
DQo+PmFwcGxpY2F0aW9ucyBhbmQNCj4+VXNpbmcgbm9kZS10YWdzIGZvciBjb25maWcvcG9saWN5
IGRyaXZlbiBnZW5lcmljIGFwcGxpY2F0aW9ucy4NCj4+DQo+PlRoYXQgc2FpZCB0aGVyZSBpcyBu
by1oYXJtIGluIHJlc2VydmluZyBhIHJhbmdlIG9mIHRhZ3MgaW4gdGhpcyBkb2N1bWVudA0KPj5h
bmQgbWVudGlvbmluZyBpdCdzIGZvciAiZnV0dXJlIiB1c2UuDQo+Pg0KPj5SZ2RzDQo+PnNocmFk
ZGhhDQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBPU1BGIFttYWls
dG86b3NwZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGhydXYgRGhvZHkNCj4+U2Vu
dDogVGh1cnNkYXksIFNlcHRlbWJlciAwNCwgMjAxNCA5OjExIEFNDQo+PlRvOiBIYW5uZXMgR3Jl
ZGxlcjsgRGhydXYgRGhvZHkNCj4+Q2M6IG9zcGZAaWV0Zi5vcmcNCj4+U3ViamVjdDogUmU6IFtP
U1BGXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBvZg0KPj5kcmFmdC1oZWdkZS1vc3BmLW5vZGUtYWRt
aW4tdGFnDQo+Pg0KPj5IaSBIYW5uZXMsIA0KPj4NCj4+PiB8DQo+Pj4gfCA+ICgyKSBJdCBzaG91
bGQgYmUgZXhwbGljaXRseSBzdGF0ZWQgdGhhdCAtIE5vIElBTkEgcmVnaXN0cnkgaXMNCj4+PiB8
ID4gcmVxdWlyZWQgdG8NCj4+PiBzdG9yZSB0aGUgbWVhbmluZyBvciBpbnRlcnByZXRhdGlvbiBv
Zi50aGUgdGFnIHZhbHVlcy4NCj4+PiB8ID4NCj4+PiB8ID4gPFNocmFkZGhhPiBJdCdzIG1lbnRp
b25lZCBpbiB0aGUgc2VjdGlvbiA0LjIgdGhhdCBubyB3ZWxsIGtub3duDQo+Pj4gfCA+IHRhZw0K
Pj4+IHZhbHVlcyB3aWxsIGJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudC4NCj4+PiB8ID4NCj4+
PiB8IFNpbmNlIGluIHRoZSBtYWlsaW5nIGxpc3QgdGhlcmUgaXMgYSBkaXNjdXNzaW9uIGFib3V0
IHBvc3NpYmlsaXR5IG9mDQo+Pj4gfCBoYXZpbmcgd2VsbCBrbm93biB0YWcgdmFsdWUgYXNzaWdu
ZWQgYnkgSUFOQS4gVGhpcyBkb2N1bWVudCBzaG91bGQNCj4+PiB8IGNsYXJpZnkgKGJhc2VkIG9u
IFdHIGNvbnNlbnN1cykgaWYgYWRtaW4gdGFncyBjYW4gYmUgYXNzaWduZWQgYnkNCj4+PiB8IElB
TkEgaW4gZnV0dXJlIGRvY3VtZW50cyBvciBub3QuIEFuZCBpZiB0aGUgYW5zd2VyIGlzIHllcywg
YQ0KPj4+IHwgc3VpdGFibGUgcmFuZ2Ugc2hvdWxkIGJlIHNldCB0byBhdm9pZCBjb25mbGljdC4N
Cj4+PiANCj4+PiBpIGhhdmUgbm8gY29uY2VybnMgd2l0aCB0aGF0IC0NCj4+PiBob3dldmVyIHBl
dGVyIHNlZW1zIGluIGZhdm9yIG9mIHVzaW5nIENBUCBCaXRzIGZvciB3ZWxsLWtub3duDQo+Pj4g
YXBwbGljYXRpb25zOw0KPj4+IA0KPj4+IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGhlYXIgb3Ro
ZXJzJyBvcGluaW9uIG9uIHRoYXQuDQo+Pg0KPj5GV0lXIEkgcHJlZmVyIENBUCBiaXRzIGFzIHdl
bGwgYW5kIHllcyEgaXQgd291bGQgaW50ZXJlc3RpbmcgdG8gaGVhciBmcm9tDQo+Pm90aGVycyEg
DQo+Pg0KPj5EaHJ1dg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4+T1NQRiBtYWlsaW5nIGxpc3QNCj4+T1NQRkBpZXRmLm9yZw0KPj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCj4+DQo+Pl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pk9TUEYgbWFpbGluZyBsaXN0
DQo+Pk9TUEZAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vc3BmDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj5PU1BGIG1haWxpbmcgbGlzdA0KPk9TUEZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCg0K


From nobody Sat Sep  6 07:47:24 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 D53671A040F for ; Sat,  6 Sep 2014 07:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.782
X-Spam-Level: *
X-Spam-Status: No, score=1.782 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RDNS_DYNAMIC=0.982] autolearn=no
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 liD5Fw364O-G for ; Sat,  6 Sep 2014 07:47:20 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id B94311A0409 for ; Sat,  6 Sep 2014 07:47:17 -0700 (PDT)
Received: from prz-workstation.zeta2.ch (108-228-12-76.lightspeed.sntcca.sbcglobal.net [108.228.12.76]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPSA id 83F1612AAE; Sat,  6 Sep 2014 16:47:06 +0200 (CEST)
Message-ID: <540B1E65.4000508@zeta2.ch>
Date: Sat, 06 Sep 2014 07:47:01 -0700
From: "A. Przygienda" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Peter Psenak 
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com> <5408B75E.4040106@zeta2.ch> <5409757C.7040600@cisco.com>
In-Reply-To: <5409757C.7040600@cisco.com>
X-TagToolbar-Keys: D20140906074701007
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: 83F1612AAE.A8F43
X-MailScanner: Found to be clean
X-MailScanner-From: prz@zeta2.ch
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/VrB55g7-xyMJ_TyUAN57byNQRaQ
Cc: ospf@ietf.org
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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, 06 Sep 2014 14:47:23 -0000

>>>>
>>>> It's also wise to add 'if the same extended prefix TLV (i.e. for same
>>>> prefix) is seen twice in same opaque LSA only use the first and force
>>>> people to put all sub-tlvs into a single tlv.
>>>
>>> it's kind of obvious, but we can add a text to be sure.
>>
>> As I see it, the purpose of an RFC is to assure interoperability. If
>> there are two
>> interpretations available of the same packet that will make two
>> solutions not interoperable,
>> the standard has to mandate the correct one.
>
> ok, we will add a text to make it clear.
ack
>
>>
>>> because existing LSA are not extensible, any additional link/prefix
>>> attributes must be advertised in a separate LSAs. We called it
>>> "extended", but it does not mean that existence of the extended LSA
>>> require existence of the base LSA. I had a text in the original SR
>>> draft around that, we can add it here too.
>>
>> yepp, once it spelled out, it's obvious but the first conclusion one
>> jumps to is that they are inter-dependent otherwise.
>
> ok, we will add a text to clarify.
ack
>
>>>> Acee, you mean remove the restriction ?  I see how some
>>>> implementations
>>>> may benefit from cramming all type-3 into the same opaque but I would
>>>> also suggest to not restrict this and remove the text.
>>>
>>> the restriction can not be removed. All the Extended Prefix TLVs that
>>> you put in a singe Extended Prefix LSA will only use a flooding scope
>>> of the Extended LSA itself.
>>
>> I still think it's not clear what the original paragraph means.
>
> prefixes can have different flooding scope. Today intra-area and
> inter-area prefixes have area flooding scope and external prefixes
> have domain wide flooding scope. You can not mix prefixes of different
> flooding scope in a single Extended Prefix LSA, because Extended
> Prefix LSA can only have a single flooding scope.
>
yes, this is now clearly spelled out.  I suggest adding that to the
draft with a MUST NOT and addition that if they are, the behavior of the
protocol is unspecified/incorrect.
>>
>>
>>>
>>>
>>>>        * what happens if the same extended prefix TLV shows up
>>>> twice in
>>>> two different opaques of same type ?  You use the one that is in lower
>>>> opaque ID ?
>>>
>>> I would call it a bug on the originator side.
>>
>> yes, but still, the draft should mandate what the desired behavior is @
>> this point in time otherwise some will use the lower ID, some higher and
>> some none of the above & the implementations will not interop ?
>
> ok, we will add a tiebreaker there.
ack

All my issues have been adressed then except concerns about the 'any
prefix in any opaque'. Let me explain.

Let's say I have an extended prefix X providing service X'.  The prefix
is advertised in opaque O_1.
If I remove it from O_1 and move it to O_2 (due to running out of space,
weak implemenation and so on)
but O_1 is flooded out there before people pick up O_2, service X' will
be interrupted.

This sounds not too bad but imagine you advertise 50 new prefixes that
slide 50 prefixes from the original
O_1.  Same for deletions. Now your protocol becomes quite fragile (if
interested further,
look @ ISIS treatement of that problem)


Waiting for new version

-- -tony


From nobody Sat Sep  6 11:05: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 986621A00D7 for ; Sat,  6 Sep 2014 11:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 SsYvS88WThnR for ; Sat,  6 Sep 2014 11:05:41 -0700 (PDT)
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 C57871A007F for ; Sat,  6 Sep 2014 11:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4633; q=dns/txt; s=iport; t=1410026740; x=1411236340; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IZUnBHn0h91FMpulWnm8sDbnLgIO0A18xLcv1jIr5Go=; b=cIbib8uDaa4qoTnRCxCUuMQeT59WRSHRJh7kaMVKrrudwgctCxF7s365 4M8jLyi0YH8yJu+nqIM8JOy0TXiM5SRUkl2x5hbCOaSiph5J3kmEgVCEY 74vKx3gbdiHQbFqreyswQ1Eldr9B/OrVjmY5/vWfsBdUkI3CZ1dON9wQh E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFAF1MC1StJA2F/2dsb2JhbABZgw1TVwTJQQqHTAGBABZ3hAQBAQQBAQFrCQIQAgEIRicLHAkCBAENBRuIJw2+AwETBI9NB4RMBYp5hkeLMpUsghuBRmyBSIEHAQEB
X-IronPort-AV: E=Sophos;i="5.04,479,1406592000"; d="scan'208";a="75579097"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 06 Sep 2014 18:05:39 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s86I5dBw002886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 18:05:39 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sat, 6 Sep 2014 13:05:38 -0500
From: "Acee Lindem (acee)" 
To: "A. Przygienda" , "Peter Psenak (ppsenak)" 
Thread-Topic: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
Thread-Index: AQHPtlGQNLZvkWuqU0uFf/90h1EvfZvOlLMAgB6rngCAAKUNAIAAZ/CAgAG9yoCAAP6WgIAAwyoAgADiowCAAfqIgP//9ESA
Date: Sat, 6 Sep 2014 18:05:37 +0000
Message-ID: 
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com> <5408B75E.4040106@zeta2.ch> <5409757C.7040600@cisco.com> <540B1E65.4000508@zeta2.ch>
In-Reply-To: <540B1E65.4000508@zeta2.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.152.196]
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/Bq2cIecptq3Vl2G97vjbH9RNEhY
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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, 06 Sep 2014 18:05:44 -0000

On 9/6/14, 10:47 AM, "A. Przygienda"  wrote:

>
>>>>>
>>>>> It's also wise to add 'if the same extended prefix TLV (i.e. for same
>>>>> prefix) is seen twice in same opaque LSA only use the first and force
>>>>> people to put all sub-tlvs into a single tlv.
>>>>
>>>> it's kind of obvious, but we can add a text to be sure.
>>>
>>> As I see it, the purpose of an RFC is to assure interoperability. If
>>> there are two
>>> interpretations available of the same packet that will make two
>>> solutions not interoperable,
>>> the standard has to mandate the correct one.
>>
>> ok, we will add a text to make it clear.
>ack
>>
>>>
>>>> because existing LSA are not extensible, any additional link/prefix
>>>> attributes must be advertised in a separate LSAs. We called it
>>>> "extended", but it does not mean that existence of the extended LSA
>>>> require existence of the base LSA. I had a text in the original SR
>>>> draft around that, we can add it here too.
>>>
>>> yepp, once it spelled out, it's obvious but the first conclusion one
>>> jumps to is that they are inter-dependent otherwise.
>>
>> ok, we will add a text to clarify.
>ack
>>
>>>>> Acee, you mean remove the restriction ?  I see how some
>>>>> implementations
>>>>> may benefit from cramming all type-3 into the same opaque but I would
>>>>> also suggest to not restrict this and remove the text.
>>>>
>>>> the restriction can not be removed. All the Extended Prefix TLVs that
>>>> you put in a singe Extended Prefix LSA will only use a flooding scope
>>>> of the Extended LSA itself.
>>>
>>> I still think it's not clear what the original paragraph means.
>>
>> prefixes can have different flooding scope. Today intra-area and
>> inter-area prefixes have area flooding scope and external prefixes
>> have domain wide flooding scope. You can not mix prefixes of different
>> flooding scope in a single Extended Prefix LSA, because Extended
>> Prefix LSA can only have a single flooding scope.
>>
>yes, this is now clearly spelled out.  I suggest adding that to the
>draft with a MUST NOT and addition that if they are, the behavior of the
>protocol is unspecified/incorrect.

I guess I still see this is a tautology since the LSA type defines the
flooding scope that need not be in the draft. If you advertise a prefix in
an LSA with a given flooding scope, then by definition, the prefix is
advertised at the flooding scope of that LSA. Let me try and reword this
so that it reflects the required flooding scope for the prefix.




>>>
>>>
>>>>
>>>>
>>>>>        * what happens if the same extended prefix TLV shows up
>>>>> twice in
>>>>> two different opaques of same type ?  You use the one that is in
>>>>>lower
>>>>> opaque ID ?
>>>>
>>>> I would call it a bug on the originator side.
>>>
>>> yes, but still, the draft should mandate what the desired behavior is @
>>> this point in time otherwise some will use the lower ID, some higher
>>>and
>>> some none of the above & the implementations will not interop ?
>>
>> ok, we will add a tiebreaker there.
>ack
>
>All my issues have been adressed then except concerns about the 'any
>prefix in any opaque'. Let me explain.
>
>Let's say I have an extended prefix X providing service X'.  The prefix
>is advertised in opaque O_1.
>If I remove it from O_1 and move it to O_2 (due to running out of space,
>weak implemenation and so on)
>but O_1 is flooded out there before people pick up O_2, service X' will
>be interrupted.
>
>This sounds not too bad but imagine you advertise 50 new prefixes that
>slide 50 prefixes from the original
>O_1.  Same for deletions. Now your protocol becomes quite fragile (if
>interested further,
>look @ ISIS treatement of that problem)

OSPFv3 has this situation today as well for Router-LSA links - in this
case, implementations will reoriginate all the changed Router-LSAs at
=B3nearly" the same time and, more often than not, the changed LSAs are
processed by other OSPFv3 Routers in the same SPF cycle. This is an
implementation issue and the protocol itself need not try and guarantee
seamless transition. However, I will think about how to add some guidance.
One of the many advantages of OSPF over ISIS is that OSPF allows for
intelligent grouping of information in separate LSAs to avoid the inherent
problems with regeneration of LSPs.

Thanks,
Acee=20




>
>
>Waiting for new version
>
>-- -tony
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf


From nobody Sat Sep  6 11:57:21 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 69C161A037B for ; Sat,  6 Sep 2014 11:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level: 
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] autolearn=no
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 w9yzHmE1WrvL for ; Sat,  6 Sep 2014 11:57:17 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 439A21A0055 for ; Sat,  6 Sep 2014 11:57:16 -0700 (PDT)
Received: from prz-workstation.zeta2.ch (108-228-12-76.lightspeed.sntcca.sbcglobal.net [108.228.12.76]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPSA id A062C12ACF; Sat,  6 Sep 2014 20:57:07 +0200 (CEST)
Message-ID: <540B58FD.80103@zeta2.ch>
Date: Sat, 06 Sep 2014 11:57:01 -0700
From: "A. Przygienda" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Acee Lindem (acee)" 
References: <20140812171918.31632.25544.idtracker@ietfa.amsl.com>  <5404E67E.6050407@zeta2.ch> <540570F2.4050507@cisco.com> <8297C1E4-1C17-435A-ABE0-21DA1B8B98AF@cisco.com> <54073E17.2090407@zeta2.ch> <540813A7.60802@cisco.com> <5408B75E.4040106@zeta2.ch> <5409757C.7040600@cisco.com> <540B1E65.4000508@zeta2.ch> 
In-Reply-To: 
X-TagToolbar-Keys: D20140906115701604
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MailScanner-ID: A062C12ACF.AD786
X-MailScanner: Found to be clean
X-MailScanner-From: prz@zeta2.ch
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/2wMV-qKYkOH90ZXz40oVpNy5DFQ
Cc: "ospf@ietf.org" 
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt
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, 06 Sep 2014 18:57:20 -0000

>>> prefixes can have different flooding scope. Today intra-area and
>>> inter-area prefixes have area flooding scope and external prefixes
>>> have domain wide flooding scope. You can not mix prefixes of different
>>> flooding scope in a single Extended Prefix LSA, because Extended
>>> Prefix LSA can only have a single flooding scope.
>>>
>> yes, this is now clearly spelled out.  I suggest adding that to the
>> draft with a MUST NOT and addition that if they are, the behavior of the
>> protocol is unspecified/incorrect.
> I guess I still see this is a tautology since the LSA type defines the
> flooding scope that need not be in the draft. If you advertise a prefix in
> an LSA with a given flooding scope, then by definition, the prefix is
> advertised at the flooding scope of that LSA. Let me try and reword this
> so that it reflects the required flooding scope for the prefix.

yes, you can see it like that, i.e. if the  flodding scopes are strictly
linked to each other, then the
text should be

    advertise  LSA-1,.. @ area scope
    advertise LSA-5,.. @ domain scope

Any LSA-1 in domain scope MUST be disregarded & so on.

That makes it tight, clean and easy to understand. I'm with you here.

>
>
> All my issues have been adressed then except concerns about the 'any
> prefix in any opaque'. Let me explain.
>
> Let's say I have an extended prefix X providing service X'.  The prefix
> is advertised in opaque O_1.
> If I remove it from O_1 and move it to O_2 (due to running out of space,
> weak implemenation and so on)
> but O_1 is flooded out there before people pick up O_2, service X' will
> be interrupted.
>
> This sounds not too bad but imagine you advertise 50 new prefixes that
> slide 50 prefixes from the original
> O_1.  Same for deletions. Now your protocol becomes quite fragile (if
> interested further,
> look @ ISIS treatement of that problem)
> OSPFv3 has this situation today as well for Router-LSA links - in this
> case, implementations will reoriginate all the changed Router-LSAs at
> łnearly" the same time and, more often than not, the changed LSAs are
> processed by other OSPFv3 Routers in the same SPF cycle. This is an
> implementation issue and the protocol itself need not try and guarantee
> seamless transition. However, I will think about how to add some guidance.
> One of the many advantages of OSPF over ISIS is that OSPF allows for
> intelligent grouping of information in separate LSAs to avoid the inherent
> problems with regeneration of LSPs.
>

Yes, I agree with the grouping but the same type of information can
still blow out an opaque (as here) and then
some, as you say, implementation guidance is, albeit not strictly
protocol specification, beneficial to have
higher quality implementations out there (which for OSPF, with lots of
people @ different clue level
implementing it, is probably more important even than for ISIS).

Yes, it's largely matter of judgement so I'm just lighting out the
complete landscape to get a draft of max quality out & don't feel
strongly either way about this one.

--- tony


From nobody Mon Sep  8 17:29: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 3AD731A031D for ; Mon,  8 Sep 2014 17:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 yGUA2zxtbumD for ; Mon,  8 Sep 2014 17:29:03 -0700 (PDT)
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 D56E21A0327 for ; Mon,  8 Sep 2014 17:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1730; q=dns/txt; s=iport; t=1410222542; x=1411432142; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z6+0n7mB8kxBfKL+bkBYSCm9A9QetOrdddKb6l7PbA0=; b=A6y5FVS0cSlRrpQl81spkn9K+y1k19GFIZ7uOgK6G3PJcosLcVqwl04N 8atpbC2YgmtUaAJygCgcMNj4AwpVkQGcwDBicgPn6QXVAxSOGOm9tUr6e W3kK2SlsdrteTqslFAm5F3eTjklQNQs9K4KE/MHKdBuYtMVZGcd1fSMy4 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0FAHBIDlStJA2F/2dsb2JhbABZgw1TUwQEygGHSgGBFhZ4hAQBAQR3EgIBCEYyGwEGAwIEEwmIOQgFvQMBF49UhEwFinmGR4QwhwKBX5NNg2FsAYFHgQcBAQE
X-IronPort-AV: E=Sophos;i="5.04,489,1406592000"; d="scan'208";a="350515827"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP; 09 Sep 2014 00:29:02 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s890T2qQ024249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Sep 2014 00:29:02 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 19:29:01 -0500
From: "Acee Lindem (acee)" 
To: OSPF WG List 
Thread-Topic: New Version Notification for draft-ietf-ospf-prefix-link-attr-01.txt
Thread-Index: AQHPy5KeNrDn3NDNnU+tyKPe9koymZv4A7iA
Date: Tue, 9 Sep 2014 00:29:01 +0000
Message-ID: 
References: <20140908182745.24078.54544.idtracker@ietfa.amsl.com>
In-Reply-To: <20140908182745.24078.54544.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <591A210CE9C05A44BCA17B9B57EBAA8B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/uA0DvdB_R5FdBZ8kVh3Gg4EsMDg
Subject: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-01.txt
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 Sep 2014 00:29:05 -0000

This version includes clarifications in response to Tony Przygienda=B9s
comments as well as some editorial changes. There are no changes to the
protocol extensions.

Thanks,
Acee=20

On 9/8/14, 2:27 PM, "internet-drafts@ietf.org" 
wrote:

>
>A new version of I-D, draft-ietf-ospf-prefix-link-attr-01.txt
>has been successfully submitted by Acee Lindem and posted to the
>IETF repository.
>
>Name:		draft-ietf-ospf-prefix-link-attr
>Revision:	01
>Title:		OSPFv2 Prefix/Link Attribute Advertisement
>Document date:	2014-09-08
>Group:		ospf
>Pages:		14
>URL:           =20
>http://www.ietf.org/internet-drafts/draft-ietf-ospf-prefix-link-attr-01.tx
>t
>Status:        =20
>https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/
>Htmlized:      =20
>http://tools.ietf.org/html/draft-ietf-ospf-prefix-link-attr-01
>Diff:          =20
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-prefix-link-attr-01
>
>Abstract:
>   OSPFv2 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisements (LSAs) as described
>   in RFC 2328.  This document defines OSPF opaque LSAs based on Type-
>   Length-Value (TLV) tuples that can be used to associate additional
>   attributes with prefixes or links.  Dependent on the application,
>   these prefixes and links may or not be advertised in the fixed-format
>   LSAs.  The OSPF opaque LSAs are optional and fully backward
>   compatible.
>
>                 =20
>       =20
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>


From nobody Mon Sep  8 17: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 4AFD71A0342 for ; Mon,  8 Sep 2014 17:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level: 
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] autolearn=no
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 MMZWXsELUT2C for ; Mon,  8 Sep 2014 17:58:10 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1451A0301 for ; Mon,  8 Sep 2014 17:58:10 -0700 (PDT)
Received: from www.zeta2.ch (localhost [127.0.0.1]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPA id 24A8A12B86; Tue,  9 Sep 2014 02:57:58 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Mon, 08 Sep 2014 17:57:56 -0700
From: prz 
To: "Acee Lindem (acee)" 
In-Reply-To: 
References: <20140908182745.24078.54544.idtracker@ietfa.amsl.com> 
Message-ID: 
X-Sender: prz@zeta2.ch
User-Agent: Roundcube Webmail/0.4.2
X-MailScanner-ID: 24A8A12B86.AED4F
X-MailScanner: Found to be clean
X-MailScanner-From: prz@zeta2.ch
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/dcZf1o1hEfeuSPlsXfgmHyF72dI
Cc: OSPF WG List 
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-01.txt
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 Sep 2014 00:58:12 -0000

 On Tue, 9 Sep 2014 00:29:01 +0000, "Acee Lindem (acee)" 
  wrote:
> This version includes clarifications in response to Tony PrzygiendaÂąs
> comments as well as some editorial changes. There are no changes to 
> the
> protocol extensions.
>
> Thanks,
> Acee
>
> On 9/8/14, 2:27 PM, "internet-drafts@ietf.org" 
> 
> wrote:
>
>>
>>A new version of I-D, draft-ietf-ospf-prefix-link-attr-01.txt
>>has been successfully submitted by Acee Lindem and posted to the
>>IETF repository.
>>

 nit:

 :  these prefixes and links may or not be

 suggest to replace with

  these prefixes and links may or _may_ not be

 Otherwise, yepp, I like the changes, they do not prescribe how to deal
 with specific duplicates too tightly but tight enough such as
 mandating the drafts hinging off this
 draft to deal with the anomalies. the coupling of opaque flooding scope
 with prefix flooding scope is nicely done, it basically says 
 application must
 make sure it floods @ correct scope but not preventing putting 
 different
 types @ same flooding scope into same opaque.

 I think all my concerns have been addressed pretty nicely.

 --- tony


>>Name:		draft-ietf-ospf-prefix-link-attr
>>Revision:	01
>>Title:		OSPFv2 Prefix/Link Attribute Advertisement
>>Document date:	2014-09-08
>>Group:		ospf
>>Pages:		14
>>URL:
>>http://www.ietf.org/internet-drafts/draft-ietf-ospf-prefix-link-attr-01.tx
>>t
>>Status:
>>https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/
>>Htmlized:
>>http://tools.ietf.org/html/draft-ietf-ospf-prefix-link-attr-01
>>Diff:
>>http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-prefix-link-attr-01
>>
>>Abstract


From nobody Fri Sep 12 05:17: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 516121A0936 for ; Fri, 12 Sep 2014 05:17:37 -0700 (PDT)
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 ZpvRuO430zwY for ; Fri, 12 Sep 2014 05:17:35 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:740]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3D61A0864 for ; Fri, 12 Sep 2014 05:17:35 -0700 (PDT)
Received: from BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) by BLUPR05MB579.namprd05.prod.outlook.com (10.141.203.18) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 12:17:12 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 12:17:10 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1024.012; Fri, 12 Sep 2014 12:17:10 +0000
From: John E Drake 
To: "Acee Lindem (acee)" , "akr@cisco.com" 
Thread-Topic: I-D Action: draft-ietf-ospf-te-metric-extensions-06.txt
Thread-Index: AQHPzoLlpj0rSMaBY0aXjoAM1h4IS5v9aWGA
Date: Fri, 12 Sep 2014 12:17:10 +0000
Message-ID: <1023a07a049a4ff58769bed20c0a51d4@BLUPR05MB562.namprd05.prod.outlook.com>
References: <20140912121228.26016.20107.idtracker@ietfa.amsl.com>
In-Reply-To: <20140912121228.26016.20107.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.11]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:;
x-forefront-prvs: 0332AACBC3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(377424004)(377454003)(189002)(105586002)(79102001)(77982001)(2656002)(31966008)(106356001)(33646002)(81542001)(74662001)(76482001)(106116001)(74502001)(95666004)(4396001)(230783001)(85306004)(90102001)(108616004)(21056001)(107046002)(99286002)(46102001)(97736003)(19580405001)(83322001)(15975445006)(86362001)(101416001)(74316001)(87936001)(64706001)(19580395003)(20776003)(85852003)(80022001)(83072002)(99396002)(76176999)(81342001)(54356999)(66066001)(76576001)(92566001)(15202345003)(50986999)(2501002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB561; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; 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-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Y3LTRe--zOm_f5Pq-j3drOhd-9g
Cc: "ospf@ietf.org" 
Subject: [OSPF] FW: I-D Action: draft-ietf-ospf-te-metric-extensions-06.txt
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, 12 Sep 2014 12:17:37 -0000

Acee and Abhay,

Would you please initiate a WGLC for the subject I-D?

Yours Irrespectively,

John

-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte=
rnet-drafts@ietf.org
Sent: Friday, September 12, 2014 5:12 AM
To: i-d-announce@ietf.org
Cc: ospf@ietf.org
Subject: I-D Action: draft-ietf-ospf-te-metric-extensions-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Open Shortest Path First IGP Working Grou=
p of the IETF.

        Title           : OSPF Traffic Engineering (TE) Metric Extensions
        Authors         : Spencer Giacalone
                          Dave Ward
                          John Drake
                          Alia Atlas
                          Stefano Previdi
	Filename        : draft-ietf-ospf-te-metric-extensions-06.txt
	Pages           : 19
	Date            : 2014-09-12

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 OSPF TE [RFC3630] 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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-te-metric-extensions-06


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie=
tf.org/ietf/1shadow-sites.txt


From nobody Fri Sep 19 10:49: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 802A61A059F for ; Fri, 19 Sep 2014 10:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level: 
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 aaDaE3bKvtjJ for ; Fri, 19 Sep 2014 10:49:12 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A9F1A063F for ; Fri, 19 Sep 2014 10:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1831; q=dns/txt; s=iport; t=1411148952; x=1412358552; h=from:to:subject:date:message-id:mime-version; bh=Lo40ARUFOjxFP9la0CnmEOErQ+AekZiVEjJCiJ6fqRs=; b=b3AjaIDav5JLbI6U3szFzIWW7r3ODLW152eCj8+zSVUaOqeHxIPCPG0F WceXGCVz6TkT3n88tv0pSM+hYoquHG8Fhf0o23fq8rYMTD52Ut944Y/6J 4Sn/aaoJXg4OThSmbsIelNbrYT23ChTpzuOjjtoHJ9mnwE4KZBMbQEZMK U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAOBrHFStJA2I/2dsb2JhbABggkdGU1vJdIdNgQQWAXmDehAdbgELATc9JwQBLYgjDcM6ARMEj32EVgWRVYQ3hweVToIcgUOCNIECAQEB
X-IronPort-AV: E=Sophos; i="5.04,556,1406592000"; d="scan'208,217"; a="79473771"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 19 Sep 2014 17:49:11 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8JHnB5B008651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 17:49:11 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 12:49:11 -0500
From: "Acee Lindem (acee)" 
To: OSPF WG List , "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" 
Thread-Topic: Working Group Last Call for  OSPF Traffic Engineering (TE) Metric Extensions  (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP1DIEHMSGequlDk2aRIP+ttVfig==
Date: Fri, 19 Sep 2014 17:49:10 +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.196]
Content-Type: multipart/alternative; boundary="_000_D041E4D53539aceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/BGZ4o3SyVH-Hcbj5YNI4cdNHDlk
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 19 Sep 2014 17:49:13 -0000

--_000_D041E4D53539aceeciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


After more than 3 years of discussion and revision, the chairs feel that we=
 are ready for a WG last call on the OSPF TE Metric extensions. While it is=
 only one piece of an end-to-end delay/loss aware routing solution, we beli=
eve that the draft, as scoped, is ready. The WG last call will end at 12:00=
 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay


--_000_D041E4D53539aceeciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <967ED7A1DA2DC04A80C1BF9F613B5A4B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable












After more than 3 years of discussion and revision, the chairs feel th=
at we are ready for a WG last call on the OSPF TE Metric extensions. While =
it is only one piece of an end-to-end delay/loss aware routing solution, we=
 believe that the draft, as scoped,
 is ready. The WG last call will end at 12:00 AM PDT on Oct 4th, 2014. For =
your convenience, here is a URL: 













Thanks,


Acee and Abhay 






--_000_D041E4D53539aceeciscocom_--


From nobody Fri Sep 19 11:25: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 C81BB1A06B7 for ; Fri, 19 Sep 2014 11:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level: 
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 Z1UGcotqyNm2 for ; Fri, 19 Sep 2014 11:25:40 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE141A069D for ; Fri, 19 Sep 2014 11:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1281; q=dns/txt; s=iport; t=1411151140; x=1412360740; h=from:to:subject:date:message-id:mime-version; bh=wPSXz/hr1o2U00JEVMVPmCPwJkiyLgHvPL0Qi2n5ws8=; b=Nfv6Pidk5RI6YHujhqQTW18GIu5MZdINmqU8FjV8sq36ybIRZYXp9xbF 8ha4LMHozx0D5/0GYuD/wUe1Gl+N0JxDZWHL0ojDCOiUojf3YH4HQa615 2yF+lQCLPQFtd4yospnhAHnQsRSkmz2O9bavPODj1uCq3qg6FWsBHSsIj 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FANxzHFStJV2T/2dsb2JhbABggkdGgS7SRhYBeYN6EIELAQsBdCcEAYhQw0kBF5RTBZFViz6VToNfgjSBAgEBAQ
X-IronPort-AV: E=Sophos; i="5.04,556,1406592000"; d="scan'208,217"; a="79484235"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 19 Sep 2014 18:25:34 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8JIPYqM020467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 18:25:34 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 13:25:34 -0500
From: "Acee Lindem (acee)" 
To: OSPF WG List , Manav Bhatia , "Carlos Pignataro (cpignata)" , Sam Aldrin , Trilok Ranganatha 
Thread-Topic: OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
Thread-Index: AQHP1DcZJX1tnOHEHUmpP91nR1Lmgg==
Date: Fri, 19 Sep 2014 18:25:33 +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.196]
Content-Type: multipart/alternative; boundary="_000_D041ED5C356Baceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/sV93DpVxDUIyA8INHHKJoDFy8DA
Subject: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
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, 19 Sep 2014 18:25:42 -0000

--_000_D041ED5C356Baceeciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We have received anonymous support for the subject document and it is requi=
red for the Seamless BFD work in the BFD WG. Hence, we are accepting it as =
a WG document.

Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.
Thanks,
Acee


--_000_D041ED5C356Baceeciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <026291D9FCC2A74491A36B3931CA49C6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







We have received anonymous support for the subject document and it is =
required for the Seamless BFD work in the BFD WG. Hence, we are accepting i=
t as a WG document. 







Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.&=
nbsp;


Thanks,


Acee









--_000_D041ED5C356Baceeciscocom_--


From nobody Fri Sep 19 12:36: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 316731A8858 for ; Fri, 19 Sep 2014 12:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.203
X-Spam-Level: 
X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 2coM7Qt1AARh for ; Fri, 19 Sep 2014 12:36:13 -0700 (PDT)
Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1D41A8888 for ; Fri, 19 Sep 2014 12:36:12 -0700 (PDT)
Received: from linne.localnet (91.97.111.198) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 123184; Fri, 19 Sep 2014 21:36:01 +0200
From: Karsten Thomann 
To: ospf@ietf.org
Date: Fri, 19 Sep 2014 21:39:14 +0200
Message-ID: <17006974.MxzxdFyur2@linne>
User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; )
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart1592451.5Z32k3EgWx"
Content-Transfer-Encoding: 7Bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 6
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/6PQNPASsNZk301f-DBbSIvxUj2k
Cc: "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" 
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 19 Sep 2014 19:36:15 -0000

This is a multi-part message in MIME format.

--nextPart1592451.5Z32k3EgWx
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"

Some Comments
- I personally don't like the word Anomalous Bit, I prefer something like Exceeded Bit
- why are some Sub TLVs are stated as do not send when not measured and others are set to all 
1's when not measured? Section 8 requires that every sub-TLV can be enabled and disabled 
individually.


Section 4.2
In my opinion the A bit should exist for the Min Delay and Max Delay Value and not only combined 
for both values, if not splitted to two Sub-TLV as there can be cases where a min delay must be 
met and others where there a max delay which should not be exeeded.

Section 4.7
"The bandwidth utilization advertised by this sub-TLV MUST be the bandwidth from the system 
originating this Sub-TLV."

I would like to change it to something like:
The bandwidth advertised by this sub-TLV MUST be the bandwidth utilization from the system 
originating this Sub-TLV.

Section 6
   Only the accelerated advertisement threshold mechanism described in
   section 6 may shorten the re-advertisement interval.

the mechanism is described in Section 5

Regards
Karsten


Am Freitag, 19. September 2014, 17:49:10 schrieb Acee Lindem:


After more than 3 years of discussion and revision, the chairs feel that we are ready for a WG last 
call on the OSPF TE Metric extensions. While it is only one piece of an end-to-end delay/loss 
aware routing solution, we believe that the draft, as scoped, is ready. The WG last call will end at 
12:00 AM PDT on Oct 4th, 2014. For your convenience, here is a URL: 


https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions[1]/


Thanks,
Acee and Abhay 





--------
[1] https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions

--nextPart1592451.5Z32k3EgWx
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="iso-8859-1"




Som=
e Comments


- I=
 personally don't like the word Anomalous Bit, I prefer something like =
Exceeded Bit


- w=
hy are some Sub TLVs are stated as do not send when not measured and ot=
hers are set to all 1's when not measured? Section 8 requires that ever=
y sub-TLV can be enabled and disabled individually.


 


 


Sec=
tion 4.2


In =
my opinion the A bit should exist for the Min Delay and Max Delay Value=
 and not only combined for both values, if not splitted to two Sub-TLV =
as there can be cases where a min delay must be met and others where th=
ere a max delay which should not be exeeded.


 


Sec=
tion 4.7


&qu=
ot;The bandwidth utilization advertised by this sub-TLV MUST be the ban=
dwidth from the system originating this Sub-TLV."


 


I w=
ould like to change it to something like:


The=
 bandwidth advertised by this sub-TLV MUST be the bandwidth utilization=
 from the system originating this Sub-TLV.


 


Sec=
tion 6


   =
Only the accelerated advertisement threshold mechanism described in
=


   =
section 6 may shorten the re-advertisement interval.


 


the=
 mechanism is described in Section 5


 


Reg=
ards


Kar=
sten


 


 


Am =
Freitag, 19. September 2014, 17:49:10 schrieb Acee Lindem:


A=
fter more than 3 years of discussion and revision, the chairs feel that=
 we are ready for a WG last call on the OSPF TE Metric extensions. Whil=
e it is only one piece of an end-to-end delay/loss aware routing soluti=
on, we believe that the draft, as scoped, is ready. The WG last call wi=
ll end at 12:00 AM PDT on Oct 4th, 2014. For your convenience, here is =
a URL:=A0


<=
br />


<=
a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-ex=
tensions">h=
ttps://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/


<=
br />


T=
hanks,


A=
cee and Abhay=A0




--nextPart1592451.5Z32k3EgWx--


From nobody Fri Sep 19 14:00: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 1ECAA1A88B4 for ; Fri, 19 Sep 2014 14:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level: 
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 6nqHPvkSiqRW for ; Fri, 19 Sep 2014 14:00:38 -0700 (PDT)
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 F2CC31A8762 for ; Fri, 19 Sep 2014 14:00:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3673; q=dns/txt; s=iport; t=1411160438; x=1412370038; h=from:to:subject:date:message-id:mime-version; bh=ymoz690W95LjCJetfZrX417FU6PIQpcK2aa9Q45kgKs=; b=Ytj4GclenZBZl/c2ANho5DoH7j1DJqRyt1ImsXw/irDv2WbImY17F8Md uMAv7shNcORCRNzJIdnKM3E8BlolyC9Dy8ysR8IGk4Xqac8mVFgUoctHM xK2QQq6D0Id5illOikChkF8PzIA4FVY3Jic5z4YGm+L2Z5PMabp7DSyLM 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsHACOZHFStJV2T/2dsb2JhbABggkdGgSEJBNFDgQUWAXmEAwECBIELAQgEDQMBAigoERQJCgQBEogqAxG8Dg2HEwEXjVSCHIRjBZFViS6CEI8MhkKCHIFDbIFIgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,557,1406592000";  d="scan'208,217";a="356697882"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 19 Sep 2014 21:00:16 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8JL0Gsb026617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 21:00:16 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 16:00:16 -0500
From: "Acee Lindem (acee)" 
To: "Acee Lindem (acee)" , OSPF WG List , "Manav Bhatia" , "Carlos Pignataro (cpignata)" , Sam Aldrin , Trilok Ranganatha 
Thread-Topic: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
Thread-Index: AQHP1Ey2G1WgAqnEikW5RdQG00YiUg==
Date: Fri, 19 Sep 2014 21:00:16 +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.196]
Content-Type: multipart/alternative; boundary="_000_D042113F3607aceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pJNUewRzLt-eU0stCimwXx_c97M
Subject: Re: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
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, 19 Sep 2014 21:00:39 -0000

--_000_D042113F3607aceeciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Of course I meant =93unanimous=94 support ;^)
Acee

From: Acee Lindem >
Date: Friday, September 19, 2014 at 2:25 PM
To: OSPF WG List >, Manav Bhatia >, "Carlos Pignataro (cpi=
gnata)" >, Sam Aldrin >, Trilok Ranganatha >
Subject: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Acc=
epted as WG Document

We have received anonymous support for the subject document and it is requi=
red for the Seamless BFD work in the BFD WG. Hence, we are accepting it as =
a WG document.

Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.
Thanks,
Acee


--_000_D042113F3607aceeciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <56050604E015464F9602AB8180277625@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Of course I meant =93unanimous=94 support ;^) 


Acee 









From: Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at=
 2:25 PM

To: OSPF WG List <ospf@ietf.org>, Manav Bhatia <manav@ionosnetworks.com>, "Carlos Pi=
gnataro (cpignata)" <cpignata=
@cisco.com>,
 Sam Aldrin <aldrin.ietf@gmail.=
com>, Trilok Ranganatha <trilok.ranganatha@alcatel-lucent.com>

Subject: [OSPF] OSPF extensions to =
advertise S-BFD Target Discriminator Accepted as WG Document















We have received anonymous support for the subject document and it is =
required for the Seamless BFD work in the BFD WG. Hence, we are accepting i=
t as a WG document. 







Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.&=
nbsp;


Thanks,


Acee
















--_000_D042113F3607aceeciscocom_--


From nobody Fri Sep 19 14:11: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 5ED781A8857 for ; Fri, 19 Sep 2014 14:11:45 -0700 (PDT)
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 niS9PrcDDf_8 for ; Fri, 19 Sep 2014 14:11:43 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E266B1A0ADE for ; Fri, 19 Sep 2014 14:11:42 -0700 (PDT)
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Fri, 19 Sep 2014 21:11:18 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1029.000; Fri, 19 Sep 2014 21:11:18 +0000
From: John E Drake 
To: "Acee Lindem (acee)" , OSPF WG List , "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" 
Thread-Topic: Working Group Last Call for  OSPF Traffic Engineering (TE) Metric Extensions  (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP1DIEHMSGequlDk2aRIP+ttVfipwI858g
Date: Fri, 19 Sep 2014 21:11:18 +0000
Message-ID: <307fc96ea481466ea2e4ffde5dea00eb@BLUPR05MB562.namprd05.prod.outlook.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 0339F89554
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(164054003)(377454003)(90102001)(19609705001)(101416001)(99396002)(74502003)(95666004)(19300405004)(106116001)(74662003)(4396001)(86362001)(19580405001)(80022003)(83322001)(107046002)(19625215002)(20776003)(19617315012)(76576001)(97736003)(92566001)(83072002)(2656002)(81342003)(108616004)(106356001)(15202345003)(33646002)(16236675004)(85852003)(15975445006)(230783001)(79102003)(77982003)(74316001)(81542003)(46102003)(76482002)(21056001)(87936001)(85306004)(107886001)(19580395003)(54356999)(99286002)(66066001)(31966008)(105586002)(50986999)(64706001)(76176999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB561; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_307fc96ea481466ea2e4ffde5dea00ebBLUPR05MB562namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/w1jP-s_i37X0NSfjxXx5LbIERjs
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 19 Sep 2014 21:11:45 -0000

--_000_307fc96ea481466ea2e4ffde5dea00ebBLUPR05MB562namprd05pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Support

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Friday, September 19, 2014 10:49 AM
To: OSPF WG List; draft-ietf-ospf-te-metric-extensions@tools.ietf.org
Subject: Working Group Last Call for OSPF Traffic Engineering (TE) Metric E=
xtensions (draft-ietf-ospf-te-metric-extensions-06.txt)


After more than 3 years of discussion and revision, the chairs feel that we=
 are ready for a WG last call on the OSPF TE Metric extensions. While it is=
 only one piece of an end-to-end delay/loss aware routing solution, we beli=
eve that the draft, as scoped, is ready. The WG last call will end at 12:00=
 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay


--_000_307fc96ea481466ea2e4ffde5dea00ebBLUPR05MB562namprd05pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Support=



 <=
/p>



Yours Irrespectively,


 <=
/p>

John



 <=
/p>







From: Acee L=
indem (acee) [mailto:acee@cisco.com]


Sent: Friday, September 19, 2014 10:49 AM

To: OSPF WG List; draft-ietf-ospf-te-metric-extensions@tools.ietf.or=
g

Subject: Working Group Last Call for OSPF Traffic Engineering (TE) M=
etric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)






 




 





After more than 3 years of =
discussion and revision, the chairs feel that we are ready for a WG last ca=
ll on the OSPF TE Metric extensions. While it is only one
 piece of an end-to-end delay/loss aware routing solution, we believe that =
the draft, as scoped, is ready. The WG last call will end at 12:00 AM PDT o=
n Oct 4th, 2014. For your convenience, here is a URL: 






 






 





Thanks,





Acee and Abhay 




 







--_000_307fc96ea481466ea2e4ffde5dea00ebBLUPR05MB562namprd05pro_--


From nobody Mon Sep 22 03:00:34 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 639F61A1A92 for ; Mon, 22 Sep 2014 03:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.287
X-Spam-Level: 
X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 4xRKZyO7ercy for ; Mon, 22 Sep 2014 03:00:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AD41A1A91 for ; Mon, 22 Sep 2014 03:00:31 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS10837; Mon, 22 Sep 2014 10:00:29 +0000 (GMT)
Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Sep 2014 10:59:52 +0100
Received: from szxeml556-mbs.china.huawei.com ([169.254.4.112]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.03.0158.001; Mon, 22 Sep 2014 17:59:45 +0800
From: Dhruv Dhody 
To: "Acee Lindem (acee)" , OSPF WG List , "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" 
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP1DIEHMSGequlDk2aRIP+ttVfipwM3iIg
Date: Mon, 22 Sep 2014 09:59:44 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B865FACE0@szxeml556-mbs.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.146.248]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/a9oPhRscdohXgEoDA6i9_kkKzmM
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 22 Sep 2014 10:00:33 -0000

Hi All,

Fully support moving this work along.=20

I have following comments/suggestions, which can handled along with other l=
ast call comments. =20

(1) Sec 1: Introduction

   This document describes extensions to OSPF TE (hereafter called "OSPF
   TE Metric Extensions"), that can be used to distribute network
   performance information (such as link delay, delay variation, packet
   loss, residual bandwidth, and available bandwidth).

Utilized Bandwidth can also be added in the above list.=20

(2) A reference to PCE should also be added along with the mention of ALTO =
server. See http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-awa=
re/
In fact the steps mentioned for the ingress in section 3 are applicable for=
 a stateful PCE as well.=20

(3)Is there a particular reason to reference RFC6375, which is MPLS-TP docu=
ment below? Or the intention was to use 6374?
  =20
   The methods for initially gathering that
   performance information, such as [RFC6375], or acting on it once it
   is distributed are outside the scope of this document.  Example
   mechanisms to measure latency, delay variation, and loss in an MPLS
   network are given in [RFC6374].

(4) Suggested change to add delay variation and to update packet-loss to ju=
st say percentage (the unit). =20
OLD:
   Delay values MUST be quantified in units of microseconds,
   packet loss MUST be quantified as a percentage of packets sent, and
   bandwidth MUST be sent as bytes per second.
NEW:
   Delay and delay variation values MUST be quantified in units of microsec=
onds,
   packet loss MUST be quantified as a percentage, and
   bandwidth MUST be sent as bytes per second.

(5) Sec 4.2.7. Reserved

   This field is reserved for future use. It MUST be set to 0 when sent
   and MUST be ignored when received.

   When only an average delay value is sent, this field is not present
   in the TLV.

I think you meant to say that the Min/Max Unidirectional Link Delay Sub-TLV=
 is not present instead of reserved field.=20

(6) Sec 4.3. Unidirectional Delay Variation Sub-TLV
  =20
   The delay variation advertised by
   this sub-TLV MUST be the delay from the local neighbor to the remote
   one (i.e. the forward path latency).

We should say 'forward path latency-variation' in this case.=20

(7) Sec 11. Security Considerations
Since the network performance metric might be considered extra sensitive in=
 some deployments it should be strongly suggested that this information mus=
t be protected from tampering using existing mechanism.=20

(8) Sec 12. IANA Considerations
This section needs updating with the list of the TLVs

(9) A reference to RFC5392 for Inter-AS-TE-v2 LSA should be added to avoid =
any confusion to the reader..=20

Nits
- Remove reference from abstract for [RFC3630]
- Update [Alto] reference to [RFC7285]
- Expand CSPF, RSVP-TE, LSA on first use
- Min/Max delay and Low/High delay are used interchangeably, suggest to use=
 only one=20

Regards,
Dhruv
=20
From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 20 September 2014 01:49
To: OSPF WG List; draft-ietf-ospf-te-metric-extensions@tools.ietf.org
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) M=
etric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)


After more than 3 years of discussion and revision, the chairs feel that we=
 are ready for a WG last call on the OSPF TE Metric extensions. While it is=
 only one piece of an end-to-end delay/loss aware routing solution, we beli=
eve that the draft, as scoped, is ready. The WG last call will end at 12:00=
 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:=A0

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay=A0


From nobody Mon Sep 22 11:29: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 85AEE1A1BF5 for ; Mon, 22 Sep 2014 11:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 UdyhC2KoXYPe for ; Mon, 22 Sep 2014 11:29:21 -0700 (PDT)
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 DEB6E1A1BF3 for ; Mon, 22 Sep 2014 11:29:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2582; q=dns/txt; s=iport; t=1411410561; x=1412620161; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bbmdX1jlqPLsO46Mz7BmQQkX/5MUvCmo+W7Obe32jkw=; b=Yh1LbDemcv5Imv2KTYvgmDPfxnY3S8iyIz4KapNqur3D+qe8U9uiMudG LCwWPoJzFrt16VKGxmGZVplXpaQvTMmPFSrV7r6oZHpIOADzYNkmdTLk7 e8zm4N62x2stdf6khhhTAPWbuBgUWh/JjuRZntqJ7w0A+YCd50UHD41tU c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsIADlqIFStJA2H/2dsb2JhbABggw5TUwQEylGHSwGBDxYBcQmEBAEBAwE6PRICAQg2EDIlAgQTCYgtCAgFxEgBF49TOoMugR0FkVeEOIcHgWGTcYNhbAGBR4ECAQEB
X-IronPort-AV: E=Sophos;i="5.04,573,1406592000"; d="scan'208";a="357266475"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 22 Sep 2014 18:28:55 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8MIStEC031419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 18:28:55 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 13:28:55 -0500
From: "Acee Lindem (acee)" 
To: "ospf@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-04.txt
Thread-Index: AQHP05UKmgvdvmZxOU+hYf9adUuIz5wN0sgA
Date: Mon, 22 Sep 2014 18:28:54 +0000
Message-ID: 
References: <20140918230522.30616.30464.idtracker@ietfa.amsl.com>
In-Reply-To: <20140918230522.30616.30464.idtracker@ietfa.amsl.com>
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="us-ascii"
Content-ID: <8D0FF928F4962B45806A117744BDD1BE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/U-yXNAxQBn9QJePlEsTmIvp2Nm0
Subject: Re: [OSPF] New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-04.txt
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, 22 Sep 2014 18:29:22 -0000

This version includes the following additions:

   1. Added IPv4 Forwarding Address sub-TLV
   2. Added restriction that OSPFv3 Extended LSA must include the required =
TLVs or be considered malformed.=20
        - E-Inter-Area-Prefix-LSA must include the Inter-Area-Prefix TLV
        - E-Inter-Area-Router-LSA must include the Inter-Area-Router TLV
        - E-AS-External-LSA must include the External-Prefix TLV
        - E-NSSA-LSA must include the External-Prefix TLV
        - E-Link-LSA must in either the IPv6-Link-Local-Address TLV or the =
IPv4-Link-Local-Address TLV.=20
  =20
      Also, considered whether we should require at least 1 link in the E-R=
outer-LSA and at least one prefix in the E-Inra-Area-Prefix-LSA but decided=
 against it.=20

   3. Added a section on the recommended handling for malformed OSPFv3 exte=
nded LSAs. =20
   4. Added a statement on graceful restart handling to the compatibility s=
ection.=20

Thanks,
Acee


On Sep 18, 2014, at 7:05 PM, internet-drafts@ietf.org wrote:

>=20
> A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-04.txt
> has been successfully submitted by Acee Lindem and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-ospf-ospfv3-lsa-extend
> Revision:	04
> Title:		OSPFv3 LSA Extendibility
> Document date:	2014-09-18
> Group:		ospf
> Pages:		36
> URL:            http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv=
3-lsa-extend-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-l=
sa-extend/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-ext=
end-04
> Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3=
-lsa-extend-04
>=20
> Abstract:
>   OSPFv3 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisement (LSA) as described in
>   RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>   links and advertised IPv6 prefixes must be advertised in separate
>   LSAs and correlated to the fixed-format LSAs.  This document extends
>   the LSA format by encoding the existing OSPFv3 LSA information in
>   Type-Length-Value (TLV) tuples and allowing advertisement of
>   additional information with additional TLVs.  Backward compatibility
>   mechanisms are also described.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20


From nobody Wed Sep 24 15:39: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 6416C1A1AD6 for ; Wed, 24 Sep 2014 15:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 Dw08TGc6uFui for ; Wed, 24 Sep 2014 15:39:35 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E965A1A1AD2 for ; Wed, 24 Sep 2014 15:39:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3810; q=dns/txt; s=iport; t=1411598374; x=1412807974; h=from:to:subject:date:message-id:mime-version; bh=5WvdLQPoEtUmj9tsdHzB3iGKcmwcn0SKZjRkSNCVGLs=; b=mTc5yiybSbxBeH/rKC+eG4kqlj/LVFDEbcrUsGPJgXvBBneYe//EmA8H oKA3I+2cIPZbmNENW22WhNq96Qn+Dof0rNPTVHbH8nHhnB8H4DMNlqi4c jP1iFqjdhSkIriyQmKyLl2kRjCMGMfc0lEFNTmplomjGd6rLydqT8yL8v E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAJFHI1StJV2U/2dsb2JhbABggkhGgSEN0hGBDRYBeoQDAQIEgQsBCAQNAwECKCgRFAkKBAESiCoDEb0KDYcgAReNboIfhGMFkV6JM4IQjw6GRoIfgUNsgUiBAgEBAQ
X-IronPort-AV: E=Sophos; i="5.04,591,1406592000"; d="scan'208,217"; a="80999377"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP; 24 Sep 2014 22:39:34 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8OMdYK2004091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 22:39:34 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 17:39:33 -0500
From: "Acee Lindem (acee)" 
To: "Acee Lindem (acee)" , OSPF WG List , "Manav Bhatia" , "Carlos Pignataro (cpignata)" , Sam Aldrin , Trilok Ranganatha 
Thread-Topic: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
Thread-Index: AQHP2EhpG1WgAqnEikW5RdQG00YiUg==
Date: Wed, 24 Sep 2014 22:39:33 +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.196]
Content-Type: multipart/alternative; boundary="_000_D048C02E395Caceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pJnwMu3IelwLnFGkxIT9z5YgL3c
Subject: Re: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
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 Sep 2014 22:39:41 -0000

--_000_D048C02E395Caceeciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Authors =96 additionally, please confirm whether or not you are aware of IP=
R related to this draft.
Thanks,
Acee

From: Acee Lindem >
Date: Friday, September 19, 2014 at 2:25 PM
To: OSPF WG List >, Manav Bhatia >, "Carlos Pignataro (cpi=
gnata)" >, Sam Aldrin >, Trilok Ranganatha >
Subject: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Acc=
epted as WG Document

We have received anonymous support for the subject document and it is requi=
red for the Seamless BFD work in the BFD WG. Hence, we are accepting it as =
a WG document.

Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.
Thanks,
Acee


--_000_D048C02E395Caceeciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <641DA8DF0049D54EA58F72362A5BDEEB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Authors =96 additionally, please confirm whether or not you are aware =
of IPR related to this draft. 


Thanks,


Acee









From: Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at=
 2:25 PM

To: OSPF WG List <ospf@ietf.org>, Manav Bhatia <manav@ionosnetworks.com>, "Carlos Pi=
gnataro (cpignata)" <cpignata=
@cisco.com>,
 Sam Aldrin <aldrin.ietf@gmail.=
com>, Trilok Ranganatha <trilok.ranganatha@alcatel-lucent.com>

Subject: [OSPF] OSPF extensions to =
advertise S-BFD Target Discriminator Accepted as WG Document















We have received anonymous support for the subject document and it is =
required for the Seamless BFD work in the BFD WG. Hence, we are accepting i=
t as a WG document. 







Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.&=
nbsp;


Thanks,


Acee
















--_000_D048C02E395Caceeciscocom_--


From nobody Wed Sep 24 15:45:32 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 2A85C1A1ADA for ; Wed, 24 Sep 2014 15:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 sbJHSc7n3Mt1 for ; Wed, 24 Sep 2014 15:45:27 -0700 (PDT)
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 BFEEF1A1AD7 for ; Wed, 24 Sep 2014 15:45:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4729; q=dns/txt; s=iport; t=1411598727; x=1412808327; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Km6BQNcmD1h3PruPokIn0JLVjhMDQUJXTQylmma5aA0=; b=dhr+wnFCsLpIvq5qC5WPk3Ema911oW0FA8YOa+y2Jrxb8OEb1eDaygLd INl1DkLjKSZDOmgVWWG+/GyVov3toxVYVOlppCqrqWNM2/+GDR/BiGcK1 pO23F54Ugxk//gIhpV6g03iDuM5vZIMAtxVpAH4WGS/fg5oZyy9oqt/Vc o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAP5II1StJV2Q/2dsb2JhbABggkhGU1vKRodLAYEMFgF6hAMBAQEEHWwCAQgEDQMBAiQEBzIUCQgCBAESG4gjDcQtARMEkA0NC4RLBZFehDqHCZVUgh+BQ2yBSIECAQEB
X-IronPort-AV: E=Sophos;i="5.04,591,1406592000";  d="scan'208,217";a="357953671"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 24 Sep 2014 22:45:27 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8OMjQBZ014203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 22:45:27 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 17:45:26 -0500
From: "Acee Lindem (acee)" 
To: OSPF WG List , "David Ward (wardd)" , "Stefano Previdi (sprevidi)" , John E Drake , Alia Atlas , Spencer Giacalone 
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP2Ek7i4SgSSVd1EqvE6Ot46My3w==
Date: Wed, 24 Sep 2014 22:45:25 +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.196]
Content-Type: multipart/alternative; boundary="_000_D048C0B73960aceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/AViGyjOVc6kQpinzC75b3mG72IU
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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 Sep 2014 22:45:30 -0000

--_000_D048C0B73960aceeciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

This subject draft in WG last call has this IPR statement:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf=
t-ietf-ospf-te-metric-extensions

Authors =96 please indicate whether or not you are aware of any other IPR.

Thanks,
Acee

From: Acee Lindem >
Date: Friday, September 19, 2014 at 1:49 PM
To: OSPF WG List >, "draft-ietf-ospf-te=
-metric-extensions@tools.ietf.org" >
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) M=
etric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)


After more than 3 years of discussion and revision, the chairs feel that we=
 are ready for a WG last call on the OSPF TE Metric extensions. While it is=
 only one piece of an end-to-end delay/loss aware routing solution, we beli=
eve that the draft, as scoped, is ready. The WG last call will end at 12:00=
 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay


--_000_D048C0B73960aceeciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <71E498B4DA74904AB6BC2C05C3861614@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







This subject draft in WG last call has this IPR statement: 













Authors =96 please indicate whether or not you are aware of any other =
IPR. 







Thanks,


Acee









From: Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at=
 1:49 PM

To: OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-te-metric-exten=
sions@tools.ietf.org" <draft-ietf-ospf-te-metric-extensions@tools.i=
etf.org>

Subject: [OSPF] Working Group Last =
Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-t=
e-metric-extensions-06.txt)




















After more than 3 years of discussion and revision, the chairs feel th=
at we are ready for a WG last call on the OSPF TE Metric extensions. While =
it is only one piece of an end-to-end delay/loss aware routing solution, we=
 believe that the draft, as scoped,
 is ready. The WG last call will end at 12:00 AM PDT on Oct 4th, 2014. For =
your convenience, here is a URL: 













Thanks,


Acee and Abhay 













--_000_D048C0B73960aceeciscocom_--


From nobody Wed Sep 24 15:48: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 7DD761A1AD7 for ; Wed, 24 Sep 2014 15:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 fIOWr7UN_3OQ for ; Wed, 24 Sep 2014 15:48:09 -0700 (PDT)
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 03BF61A1A87 for ; Wed, 24 Sep 2014 15:48:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4729; q=dns/txt; s=iport; t=1411598889; x=1412808489; h=from:to:subject:date:message-id:mime-version; bh=tR0tjaVIFxJ5vF7y7x6IQAkVjs5N6W6sbfCCJIv3Dbg=; b=Sh5Mw0hdDWqgh79KAe++oQXZWZ6g5+CowiqoO3iOxf7+P86aljY3YONb PQlRTLUjP3ONDac0qeg8ixua8jrn0tba84kpBScqNnmZHfTINSYJfcR+B 2lG2L+pZ67exi6bffZilPdf2/AfrxZRSxoeB3OfPh8eZLW1DJOx7qnWhA o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAP5II1StJV2S/2dsb2JhbABggkhGU1vKRodLgQ0WAXqEAwECBB1uAQgEDQMBAiQEORQJCgQBEhuIIw3ELQETBI88EQE/DYRWBZFehDqHCZVUgh+BQ2yBDzmBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,591,1406592000";  d="scan'208,217";a="357964683"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 24 Sep 2014 22:48:08 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8OMm8L7001980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 22:48:08 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 17:48:08 -0500
From: "Acee Lindem (acee)" 
To: OSPF WG List , "David Ward (wardd)" , "Stefano Previdi (sprevidi)" , John E Drake , Alia Atlas , Spencer Giacalone 
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt) (Corrected Email Address)
Thread-Index: AQHP2EmbwdN+n3WMQU+Z71ZowyJTEQ==
Date: Wed, 24 Sep 2014 22:48:07 +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.196]
Content-Type: multipart/alternative; boundary="_000_D048C249396Daceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0zTrJSWrPxPA23EQPh5cSzNgOoU
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt) (Corrected Email Address)
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 Sep 2014 22:48:11 -0000

--_000_D048C249396Daceeciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

This subject draft in WG last call has this IPR statement:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf=
t-ietf-ospf-te-metric-extensions

Authors =96 please indicate whether or not you are aware of any other IPR.

Thanks,
Acee

From: Acee Lindem >
Date: Friday, September 19, 2014 at 1:49 PM
To: OSPF WG List >, "draft-ietf-ospf-te=
-metric-extensions@tools.ietf.org" >
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) M=
etric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)


After more than 3 years of discussion and revision, the chairs feel that we=
 are ready for a WG last call on the OSPF TE Metric extensions. While it is=
 only one piece of an end-to-end delay/loss aware routing solution, we beli=
eve that the draft, as scoped, is ready. The WG last call will end at 12:00=
 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay


--_000_D048C249396Daceeciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







This subject draft in WG last call has this IPR statement: 













Authors =96 please indicate whether or not you are aware of any other =
IPR. 







Thanks,


Acee









From: Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at=
 1:49 PM

To: OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-te-metric-exten=
sions@tools.ietf.org" <draft-ietf-ospf-te-metric-extensions@tools.i=
etf.org>

Subject: [OSPF] Working Group Last =
Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-t=
e-metric-extensions-06.txt)




















After more than 3 years of discussion and revision, the chairs feel th=
at we are ready for a WG last call on the OSPF TE Metric extensions. While =
it is only one piece of an end-to-end delay/loss aware routing solution, we=
 believe that the draft, as scoped,
 is ready. The WG last call will end at 12:00 AM PDT on Oct 4th, 2014. For =
your convenience, here is a URL: 













Thanks,


Acee and Abhay 













--_000_D048C249396Daceeciscocom_--


From nobody Wed Sep 24 16:35: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 9DB001A1B3F for ; Wed, 24 Sep 2014 16:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 g9Snma_-lBbh for ; Wed, 24 Sep 2014 16:35:44 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F12C1A1B5D for ; Wed, 24 Sep 2014 16:35:42 -0700 (PDT)
Received: by mail-ob0-f171.google.com with SMTP id wp4so4065456obc.30 for ; Wed, 24 Sep 2014 16:35:41 -0700 (PDT)
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:content-transfer-encoding; bh=lOIdMK709WKfm0feeOxpfffuZcP1bTb87Zs9oeuhzmg=; b=CYE7vDj6BDRMxe190HzhgfIPHFVR37Y89vcc1LEsqBjHf9ziNK89ffSfcb8O0PUJ9B uLPH81lVEK0gf8ZCGTzDD/IxK+GSR4xFDp7plZyTxFm+PcVTGErDI7vFj1lQiW2opqD0 APhnqBpVh8By3GCIIa5L4snAs30F/P7fTOnkkVzuA1YbFUh4HttQUe0IXqcCtqAalTSh TdLeqvfdK3upJdS4OcoFHV+MBlUbPneIB4XOkw1EwRpI5eYZ4bu2kdK2C74oCh77WJmo a1E0v/A/FzeYctks0nhrM6cC8nYQJoLDmMvRboud9iJZL/fFFqD+rwBsWy5qwmDO5lcX 8ItA==
MIME-Version: 1.0
X-Received: by 10.60.81.231 with SMTP id d7mr10096413oey.22.1411601741783; Wed, 24 Sep 2014 16:35:41 -0700 (PDT)
Received: by 10.76.13.5 with HTTP; Wed, 24 Sep 2014 16:35:41 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 25 Sep 2014 05:05:41 +0530
Message-ID: 
From: Manav Bhatia 
To: "Acee Lindem (acee)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/uscShTvnp7zkwxU9ShqN1x1B4Qo
Cc: Sam Aldrin , OSPF WG List , Trilok Ranganatha , Manav Bhatia , "Carlos Pignataro \(cpignata\)" 
Subject: Re: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
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 Sep 2014 23:35:45 -0000

Hi Acee,

No IPR from my side.

Cheers, Manav

On Thu, Sep 25, 2014 at 4:09 AM, Acee Lindem (acee)  wrote:
> Authors =E2=80=93 additionally, please confirm whether or not you are awa=
re of IPR
> related to this draft.
> Thanks,
> Acee
>
> From: Acee Lindem 
> Date: Friday, September 19, 2014 at 2:25 PM
> To: OSPF WG List , Manav Bhatia ,
> "Carlos Pignataro (cpignata)" , Sam Aldrin
> , Trilok Ranganatha
> 
> Subject: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator
> Accepted as WG Document
>
> We have received anonymous support for the subject document and it is
> required for the Seamless BFD work in the BFD WG. Hence, we are accepting=
 it
> as a WG document.
>
> Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.
> Thanks,
> Acee
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>


From nobody Wed Sep 24 18:07: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 76BB01A2119 for ; Wed, 24 Sep 2014 18:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 Id7K8LvcDVoV for ; Wed, 24 Sep 2014 18:07:02 -0700 (PDT)
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 53C8F1A1BFD for ; Wed, 24 Sep 2014 18:07:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7285; q=dns/txt; s=iport; t=1411607222; x=1412816822; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5+UI7NWGlvEMdXQ7RJ1WG+XkCg0tsjPztsdu6AVmQ5U=; b=V5rwzf41BXZAJipQ+zRUNpNoOBeh6uQhdYmtTNW0sGgJmd7SotXkuM8W 0Uxg4LvkvR81LlgxQjzz5sE8uTqZsmMKVAZ5mmJySpIiVxKKtj33GFJFe go1dO0J/5EyrA7m3nEGubWltCPreH8eXAZJggdEeuWvlP4B1PxWrJy+ej Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFAFhpI1StJV2Q/2dsb2JhbABggkhGU1vKOgELh0sBgQkWAXqEAwEBAQQBAQEaUQsQAgEIEQMBAiQEByEGCxQJCAIEDgUbiA8DEQ28cw2HIAETBI1ugh8NBAeESwWRXoQ6hHmCEI8OhkaCH4FDbIFIgQIBAQE
X-IronPort-AV: E=Sophos; i="5.04,592,1406592000"; d="scan'208,217"; a="81022370"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 25 Sep 2014 01:07:00 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8P170cs001879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 01:07:00 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 20:07:00 -0500
From: "Acee Lindem (acee)" 
To: Spencer Giacalone 
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP2ElEIsjx7Bl7kUuY1nqG2969V5wRPS+A///dBAA=
Date: Thu, 25 Sep 2014 01:07:00 +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.196]
Content-Type: multipart/alternative; boundary="_000_D048E2DF3981aceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/T1Zay6Bn3jWBxCCr2ne022dpolg
Cc: OSPF WG List 
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 25 Sep 2014 01:07:04 -0000

--_000_D048E2DF3981aceeciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks Spencer =96 copying WG

From: Spencer Giacalone >
Date: Wednesday, September 24, 2014 at 7:12 PM
To: Acee Lindem >
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (T=
E) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

I am not

On Wed, Sep 24, 2014 at 11:45 PM, Acee Lindem (acee) > wrote:
This subject draft in WG last call has this IPR statement:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf=
t-ietf-ospf-te-metric-extensions

Authors =96 please indicate whether or not you are aware of any other IPR.

Thanks,
Acee

From: Acee Lindem >
Date: Friday, September 19, 2014 at 1:49 PM
To: OSPF WG List >, "draft-ietf-ospf-te=
-metric-extensions@tools.ietf.org" >
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) M=
etric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)


After more than 3 years of discussion and revision, the chairs feel that we=
 are ready for a WG last call on the OSPF TE Metric extensions. While it is=
 only one piece of an end-to-end delay/loss aware routing solution, we beli=
eve that the draft, as scoped, is ready. The WG last call will end at 12:00=
 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf



--_000_D048E2DF3981aceeciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Thanks Spencer =96 copying WG









From: Spencer Giacalone <spencer.giacalone@gmail.com>=


Date: Wednesday, September 24, 2014=
 at 7:12 PM

To: Acee Lindem <acee@cisco.com>

Subject: Re: [OSPF] Working Group L=
ast Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-os=
pf-te-metric-extensions-06.txt)















I am not





On Wed, Sep 24, 2014 at 11:45 PM, Acee Lindem (a=
cee) 
<acee@cisco.com&=
gt; wrote:






This subject draft in WG last call has this IPR statement: 













Authors =96 please indicate whether or not you are aware of any other =
IPR. 







Thanks,


Acee









From: Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at=
 1:49 PM

To: OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-te-metric-extensions@tools.ietf.org"
 <draft-ietf-ospf-te-metric-extensions@tools.ietf.org&=
gt;

Subject: [OSPF] Working Group Last =
Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-t=
e-metric-extensions-06.txt)




















After more than 3 years of discussion and revision, the chairs feel th=
at we are ready for a WG last call on the OSPF TE Metric extensions. While =
it is only one piece of an end-to-end delay/loss aware routing solution, we=
 believe that the draft, as scoped,
 is ready. The WG last call will end at 12:00 AM PDT on Oct 4th, 2014. For =
your convenience, here is a URL: 













Thanks,


Acee and Abhay 













_______________________________________________

OSPF mailing list

OSPF@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/ospf





















--_000_D048E2DF3981aceeciscocom_--


From nobody Thu Sep 25 00:54: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 E1B2A1A0298 for ; Thu, 25 Sep 2014 00:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 75_5QYLrVRD7 for ; Thu, 25 Sep 2014 00:54:49 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9FF1A028E for ; Thu, 25 Sep 2014 00:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4798; q=dns/txt; s=iport; t=1411631689; x=1412841289; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=82AbgcAd69TujBKK4cGH91Q3HdnhoV9iHHxDAh4nz8w=; b=DR2E2o1beKleppcxtDBQqOLHnPkDcgC/+jpzuOpgjC3I0q5wmze1VFRx PGHpz0DT9XSa1HYl76lvqWLSrv4o+ps4RgJpqoJm95dPERhqEwvQiElC+ IzPL3gwL/o/5Al6455oWwSynRxS1TO5KNbsdEBasZj976UbSSlNAzBhYI 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYFADHJI1StJA2N/2dsb2JhbABggkgjI4EgCtInAYEHFgF6hAMBAQEEeRACAQgEDQMBAigHIREUCQgCBA4FiCoDEQG7Vg2HIAEXjW6CHxEHgy6BHQWPRoIYiTOCEI8OhkaCH4FDbIJKAQEB
X-IronPort-AV: E=Sophos; i="5.04,595,1406592000"; d="scan'208,217"; a="81099435"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 25 Sep 2014 07:54:48 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8P7sm1R003999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 07:54:48 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 02:54:48 -0500
From: "Carlos Pignataro (cpignata)" 
To: "Acee Lindem (acee)" 
Thread-Topic: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
Thread-Index: AQHP2EhpG1WgAqnEikW5RdQG00YiUpwRe2Nc
Date: Thu, 25 Sep 2014 07:54:47 +0000
Message-ID: <5981C2EA-2E44-4D98-8528-C4E66DC69FA0@cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_5981C2EA2E444D988528C4E66DC69FA0ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/dpEIHpPVfBUJJ8zzZbSIRzFjyTk
Cc: Sam Aldrin , OSPF WG List , Trilok Ranganatha , Manav Bhatia 
Subject: Re: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Accepted as WG Document
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, 25 Sep 2014 07:54:51 -0000

--_000_5981C2EA2E444D988528C4E66DC69FA0ciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Acee,

I am not aware of any IPR related to this document.

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Sep 25, 2014, at 12:39 AM, Acee Lindem (acee) > wrote:

Authors =96 additionally, please confirm whether or not you are aware of IP=
R related to this draft.
Thanks,
Acee

From: Acee Lindem >
Date: Friday, September 19, 2014 at 2:25 PM
To: OSPF WG List >, Manav Bhatia >, "Carlos Pignataro (cpi=
gnata)" >, Sam Aldrin >, Trilok Ranganatha >
Subject: [OSPF] OSPF extensions to advertise S-BFD Target Discriminator Acc=
epted as WG Document

We have received anonymous support for the subject document and it is requi=
red for the Seamless BFD work in the BFD WG. Hence, we are accepting it as =
a WG document.

Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.
Thanks,
Acee


--_000_5981C2EA2E444D988528C4E66DC69FA0ciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Acee,







I am not aware of any IPR related to this document. 







Thanks!



Excuze typofraphicak errows





On Sep 25, 2014, at 12:39 AM, Acee Lindem (acee) <acee@cisco.com> wrote:










Authors =96 additionally, please confirm whether or not you are aware =
of IPR related to this draft. 


Thanks,


Acee









From: Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at=
 2:25 PM

To: OSPF WG List <ospf@ietf.org>, Manav Bhatia <manav@ionosnetworks.com>, "Carlos Pi=
gnataro (cpignata)" <cpignata=
@cisco.com>,
 Sam Aldrin <aldrin.ietf@gmail.=
com>, Trilok Ranganatha <trilok.ranganatha@alcatel-lucent.com>

Subject: [OSPF] OSPF extensions to =
advertise S-BFD Target Discriminator Accepted as WG Document















We have received anonymous support for the subject document and it is =
required for the Seamless BFD work in the BFD WG. Hence, we are accepting i=
t as a WG document. 







Authors, please resubmit as draft-ietf-ospf-bfd-descriminator-00.txt.&=
nbsp;


Thanks,


Acee



















--_000_5981C2EA2E444D988528C4E66DC69FA0ciscocom_--


From nobody Thu Sep 25 06:59: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 28AA41A00D4 for ; Thu, 25 Sep 2014 06:59:27 -0700 (PDT)
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 rUa-loM7gaRq for ; Thu, 25 Sep 2014 06:59:24 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02E61A00B7 for ; Thu, 25 Sep 2014 06:59:24 -0700 (PDT)
Received: from BL2PR05MB195.namprd05.prod.outlook.com (10.242.198.149) by BL2PR05MB131.namprd05.prod.outlook.com (10.242.198.25) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Thu, 25 Sep 2014 13:59:23 +0000
Received: from DM2PR05MB573.namprd05.prod.outlook.com (10.141.159.16) by BL2PR05MB195.namprd05.prod.outlook.com (10.242.198.149) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 13:59:22 +0000
Received: from DM2PR05MB573.namprd05.prod.outlook.com ([10.141.159.16]) by DM2PR05MB573.namprd05.prod.outlook.com ([10.141.159.16]) with mapi id 15.00.1034.003; Thu, 25 Sep 2014 13:59:22 +0000
From: John E Drake 
To: "Acee Lindem (acee)" , OSPF WG List , "David Ward (wardd)" , "Stefano Previdi (sprevidi)" , Alia Atlas , Spencer Giacalone 
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP2Ek9g5sMyPGYVkCs3lHhDoM0FZwR4SuQ
Date: Thu, 25 Sep 2014 13:59:22 +0000
Message-ID: <3f9f2001bb53497bbfe258bb3b0b0dbc@DM2PR05MB573.namprd05.prod.outlook.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB195;UriScan:;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(164054003)(107886001)(33646002)(85306004)(19300405004)(74502003)(83322001)(101416001)(74316001)(97736003)(15202345003)(15975445006)(1941001)(108616004)(107046002)(19609705001)(19580395003)(50986999)(19580405001)(4396001)(74662003)(86362001)(19617315012)(92566001)(66066001)(76176999)(106116001)(54356999)(106356001)(85852003)(2656002)(87936001)(83072002)(46102003)(76576001)(31966008)(81542003)(64706001)(90102001)(19625215002)(105586002)(95666004)(120916001)(81342003)(80022003)(230783001)(99396003)(76482002)(21056001)(10300001)(79102003)(16236675004)(77982003)(20776003)(99286002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB195; H:DM2PR05MB573.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_3f9f2001bb53497bbfe258bb3b0b0dbcDM2PR05MB573namprd05pro_"
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/cF8ldVD25OUMpYVySeLUu6L8aD4
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 25 Sep 2014 13:59:27 -0000

--_000_3f9f2001bb53497bbfe258bb3b0b0dbcDM2PR05MB573namprd05pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Wednesday, September 24, 2014 3:45 PM
To: OSPF WG List; David Ward (wardd); Stefano Previdi (sprevidi); John E Dr=
ake; Alia Atlas; Spencer Giacalone
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (T=
E) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

This subject draft in WG last call has this IPR statement:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf=
t-ietf-ospf-te-metric-extensions

Authors - please indicate whether or not you are aware of any other IPR.

Thanks,
Acee

From: Acee Lindem >
Date: Friday, September 19, 2014 at 1:49 PM
To: OSPF WG List >, "draft-ietf-ospf-te=
-metric-extensions@tools.ietf.org" >
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) M=
etric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)


After more than 3 years of discussion and revision, the chairs feel that we=
 are ready for a WG last call on the OSPF TE Metric extensions. While it is=
 only one piece of an end-to-end delay/loss aware routing solution, we beli=
eve that the draft, as scoped, is ready. The WG last call will end at 12:00=
 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay


--_000_3f9f2001bb53497bbfe258bb3b0b0dbcDM2PR05MB573namprd05pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I am not aware of any IPR=
.


 <=
/p>



Yours Irrespectively,


 <=
/p>

John



 <=
/p>







From: Acee L=
indem (acee) [mailto:acee@cisco.com]


Sent: Wednesday, September 24, 2014 3:45 PM

To: OSPF WG List; David Ward (wardd); Stefano Previdi (sprevidi); Jo=
hn E Drake; Alia Atlas; Spencer Giacalone

Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Enginee=
ring (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)






 




This subject draft in WG la=
st call has this IPR statement: 






 






 





Authors – please indi=
cate whether or not you are aware of any other IPR. =







 





Thanks,





Acee






 





From:
Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at 1:49 PM

To: OSPF WG List <ospf@ietf.org<=
/a>>, "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" &l=
t;dr=
aft-ietf-ospf-te-metric-extensions@tools.ietf.org>

Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering=
 (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)<=
/o:p>






 











 





After more than 3 years of =
discussion and revision, the chairs feel that we are ready for a WG last ca=
ll on the OSPF TE Metric extensions. While it is only one
 piece of an end-to-end delay/loss aware routing solution, we believe that =
the draft, as scoped, is ready. The WG last call will end at 12:00 AM PDT o=
n Oct 4th, 2014. For your convenience, here is a URL: 






 






 





Thanks,





Acee and Abhay 




 













--_000_3f9f2001bb53497bbfe258bb3b0b0dbcDM2PR05MB573namprd05pro_--


From nobody Thu Sep 25 07:17:32 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 E814F1A6FF7 for ; Thu, 25 Sep 2014 07:17:18 -0700 (PDT)
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 dsG12qcaGOtS for ; Thu, 25 Sep 2014 07:17:10 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385C71A6FF5 for ; Thu, 25 Sep 2014 07:17:09 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id k48so8057673wev.2 for ; Thu, 25 Sep 2014 07:17:07 -0700 (PDT)
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=YtWBaL6TPncapsFK/ZAY0yPf2lv2ohwA0tXRYxX4bpE=; b=Yog8tolqEqKAfZhUxtgGSEAaT3MOctis2f26xBPgnMSHjeqBV7AIxIkjM/hN/Ddw0k YmOeUuBjmjJxG3Kbdrk3zQXT/HSrWvxCpM5S9riihX0YtprPOl/c8BJYMDlbyrclrN3m e2sLOUcFeP5HjDHJ1OmoPhIx3uFmm+FzzYjz77BmVVCXwlB+btmFq+um6FXa0iJZPhgC 8kFBgiOzcH39mgbVSxYg831nZCiZo8GYZnHgPBLqFCfCZtC3oYWHUV9P0fRQ1KBXeGzz gAZurjaMmPVQT3404nreb6b1VaFxvYoy5KiSQCoQ7Gp91rGU6/QrNmEtta2KzN/thDug K+zg==
MIME-Version: 1.0
X-Received: by 10.180.105.41 with SMTP id gj9mr19406442wib.3.1411654627813; Thu, 25 Sep 2014 07:17:07 -0700 (PDT)
Received: by 10.217.69.138 with HTTP; Thu, 25 Sep 2014 07:17:07 -0700 (PDT)
Received: by 10.217.69.138 with HTTP; Thu, 25 Sep 2014 07:17:07 -0700 (PDT)
In-Reply-To: <3f9f2001bb53497bbfe258bb3b0b0dbc@DM2PR05MB573.namprd05.prod.outlook.com>
References:   <3f9f2001bb53497bbfe258bb3b0b0dbc@DM2PR05MB573.namprd05.prod.outlook.com>
Date: Thu, 25 Sep 2014 10:17:07 -0400
Message-ID: 
From: Alia Atlas 
To: John E Drake 
Content-Type: multipart/alternative; boundary=f46d04428262a2efde0503e47475
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/nwhAHZVIHQTWWJhNMhi-_Rs4-ic
Cc: Spencer Giacalone , OSPF List , Alia Atlas , "David Ward \(wardd\)" 
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 25 Sep 2014 14:17:19 -0000

--f46d04428262a2efde0503e47475
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I am also not aware of any other IPR.

Alia
On Sep 25, 2014 9:59 AM, "John E Drake"  wrote:

>  I am not aware of any IPR.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Acee Lindem (acee) [mailto:acee@cisco.com]
> *Sent:* Wednesday, September 24, 2014 3:45 PM
> *To:* OSPF WG List; David Ward (wardd); Stefano Previdi (sprevidi); John
> E Drake; Alia Atlas; Spencer Giacalone
> *Subject:* Re: [OSPF] Working Group Last Call for OSPF Traffic
> Engineering (TE) Metric Extensions
> (draft-ietf-ospf-te-metric-extensions-06.txt)
>
>
>
> This subject draft in WG last call has this IPR statement:
>
>
>
>
> https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddr=
aft-ietf-ospf-te-metric-extensions
>
>
>
> Authors =E2=80=93 please indicate whether or not you are aware of any oth=
er IPR.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Acee Lindem 
> *Date: *Friday, September 19, 2014 at 1:49 PM
> *To: *OSPF WG List , "
> draft-ietf-ospf-te-metric-extensions@tools.ietf.org" <
> draft-ietf-ospf-te-metric-extensions@tools.ietf.org>
> *Subject: *[OSPF] Working Group Last Call for OSPF Traffic Engineering
> (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
>
>
>
>
>
> After more than 3 years of discussion and revision, the chairs feel that
> we are ready for a WG last call on the OSPF TE Metric extensions. While i=
t
> is only one piece of an end-to-end delay/loss aware routing solution, we
> believe that the draft, as scoped, is ready. The WG last call will end at
> 12:00 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/
>
>
>
> Thanks,
>
> Acee and Abhay
>
>
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>

--f46d04428262a2efde0503e47475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I am also not aware of any other IPR.


Alia


On Sep 25, 2014 9:59 AM, "John E Drake"=
; <jdrake@juniper.net> wrot=
e:











I am not aware of any IPR=
.


=C2=A0




Yours Irrespectively,<=
/u>


=C2=A0


John=





=C2=A0








From: Acee L=
indem (acee) [mailto:ac=
ee@cisco.com]


Sent: Wednesday, September 24, 2014 3:45 PM

To: OSPF WG List; David Ward (wardd); Stefano Previdi (sprevidi); Jo=
hn E Drake; Alia Atlas; Spencer Giacalone

Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Enginee=
ring (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)






=C2=A0




This subject draft in WG la=
st call has this IPR statement:=C2=A0






=C2=A0=








=C2=A0=







Authors =E2=80=93 please in=
dicate whether or not you are aware of any other IPR.=C2=A0






=C2=A0=







Thanks,






Acee





=C2=A0=







From:
Acee Lindem <acee@cisco.com>

Date: Friday, September 19, 2014 at 1:49 PM

To: OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-te-metric-ex=
tensions@tools.ietf.org" <draft-ietf-ospf-te-metr=
ic-extensions@tools.ietf.org>

Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering=
 (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)






=C2=A0=













=C2=A0=







After more than 3 years of =
discussion and revision, the chairs feel that we are ready for a WG last ca=
ll on the OSPF TE Metric extensions. While it is only one
 piece of an end-to-end delay/loss aware routing solution, we believe that =
the draft, as scoped, is ready. The WG last call will end at 12:00 AM PDT o=
n Oct 4th, 2014. For your convenience, here is a URL:=C2=A0






=C2=A0=








=C2=A0=







Thanks,






Acee and Abhay=C2=A0=





=C2=A0=
















_______________________________________________

OSPF mailing list

OSPF@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/ospf




--f46d04428262a2efde0503e47475--


From nobody Thu Sep 25 09:31: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 9DBE91A6FF9 for ; Thu, 25 Sep 2014 09:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 13d9jevuC8Sm for ; Thu, 25 Sep 2014 09:31:11 -0700 (PDT)
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 4CC6B1A01CB for ; Thu, 25 Sep 2014 09:31:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1258; q=dns/txt; s=iport; t=1411662671; x=1412872271; h=from:to:cc:subject:date:message-id:mime-version; bh=iu5Whe1snxHfC0BO50OtJVsElfKphwhFR0TeEJnQB+I=; b=a34vG4lRqkdcZpa2XtU/JhvDcZqxMzpMxrRHtVW4FYAYrT+zpkswoGrs VVuFrlU55MUFqzExn/FJQrVo9uSCQzdDnEP7IPDfD2sug5ObAv7rn5RcH 14/vVsbK+p1QTdrIwJAlOCuuO+1nTTUVRuqIdiYPQGkBzRQX+Z5296Qnd I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAJxCJFStJA2J/2dsb2JhbABggkhGgS7SOIEGFgF7g3oQeRIBCwF0JwQBDYhDwVcBF5AehFIFkWCLQ5VWgiCBQ4I0gQIBAQE
X-IronPort-AV: E=Sophos; i="5.04,598,1406592000"; d="scan'208,217"; a="81260067"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 25 Sep 2014 16:31:10 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8PGVAwH011622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 16:31:10 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 11:31:10 -0500
From: "Acee Lindem (acee)" 
To: Uma Chunduri , Xiaohu Xu ,  Manav Bhatia 
Thread-Topic: Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-routable-ip-address-01
Thread-Index: AQHP2N4d8MxCsg1MtEO5yO4HvpFm2Q==
Date: Thu, 25 Sep 2014 16:31:10 +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.196]
Content-Type: multipart/alternative; boundary="_000_D049BB8C3A2Faceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/P9lWTeoS_0eiLAoKS8l4eSpm6ps
Cc: OSPF WG List 
Subject: [OSPF] Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-routable-ip-address-01
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, 25 Sep 2014 16:31:12 -0000

--_000_D049BB8C3A2Faceeciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Uma, Xiaohu, Manav,

We are accepting this draft as a WG document. Please reissue as draft-ietf-=
xu-ospf-routable-ip-address-00.txt. Also, please indicate whether or not yo=
u are aware of any IPR claims related to the draft.

Thanks,
Acee

--_000_D049BB8C3A2Faceeciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <351DD0C10E65494DA0D3B3426A54BD9B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Uma, Xiaohu, Manav, 







We are accepting this draft as a WG document. Please reissue as draft-=
ietf-xu-ospf-routable-ip-address-00.txt. Also, please indicate whether or n=
ot you are aware of any IPR claims related to the draft. 







Thanks,


Acee 




--_000_D049BB8C3A2Faceeciscocom_--


From nobody Thu Sep 25 09:52: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 A5DB61A86F2 for ; Thu, 25 Sep 2014 09:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 njOkoD5hi9AX for ; Thu, 25 Sep 2014 09:52:34 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBEC1A8706 for ; Thu, 25 Sep 2014 09:52:34 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id wm4so5611777obc.10 for ; Thu, 25 Sep 2014 09:52:31 -0700 (PDT)
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=WFGIYp8LjUh8LCOn5lYmXXkKXn4eyieFOGzmtj1Nvig=; b=NyFVTPTJUj7x4nWYGjO2b+c9lgrbJX+qeCHnGIMpZzUSmoN/pj1quxPj/DxFS8DVvn EczPPHElPD5/L2EoX7o7cZWXD/DRUBwK8LLmNy5mkGIdYnqfvSgrHN+y2RAbV8p1iNQX Kil0+Qps+3xXO0E/fKLI6aSLsjuDGFU1uGz4xaw5DHjpnyxoyQglybXYt6ge3o2FHAtl 2oerlofj0nC4/rGvATn2eOfDudZCWjUtk94csQslMyc9nb8CR/bzBqiIbz2kAjui+uR3 5K3Qde4okZtv0y/U7O/6pFm4A+N4ClNcKGxuj51b8k55uOBH46s/mc53ZDlKoHGucv6S 8PTw==
MIME-Version: 1.0
X-Received: by 10.60.147.130 with SMTP id tk2mr15833616oeb.68.1411663951747; Thu, 25 Sep 2014 09:52:31 -0700 (PDT)
Received: by 10.76.13.5 with HTTP; Thu, 25 Sep 2014 09:52:31 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 25 Sep 2014 22:22:31 +0530
Message-ID: 
From: Manav Bhatia 
To: "Acee Lindem (acee)" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/j_KUC4xfSrQ6nVkDIrxwWNW-xS4
Cc: OSPF WG List , Manav Bhatia 
Subject: Re: [OSPF] Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-routable-ip-address-01
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, 25 Sep 2014 16:52:38 -0000

Hi Acee,

No IPR from my side.

We'll publish it as a WG doc soon.

Cheers, Manav

On Thu, Sep 25, 2014 at 10:01 PM, Acee Lindem (acee)  wrote:
> Uma, Xiaohu, Manav,
>
> We are accepting this draft as a WG document. Please reissue as
> draft-ietf-xu-ospf-routable-ip-address-00.txt. Also, please indicate whether
> or not you are aware of any IPR claims related to the draft.
>
> Thanks,
> Acee
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>


From nobody Thu Sep 25 10:36: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 8A1421A871A for ; Thu, 25 Sep 2014 10:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fY4PTO8pepqs for ; Thu, 25 Sep 2014 10:36:25 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF411A014F for ; Thu, 25 Sep 2014 10:36:24 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-f2-5423fc537ca1
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.87.05330.35CF3245; Thu, 25 Sep 2014 13:28:19 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 25 Sep 2014 13:36:22 -0400
From: Uma Chunduri 
To: Manav Bhatia , "Acee Lindem (acee)" 
Thread-Topic: [OSPF] Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-routable-ip-address-01
Thread-Index: AQHP2N4d8MxCsg1MtEO5yO4HvpFm2ZwSU4OA///I1eA=
Date: Thu, 25 Sep 2014 17:36:22 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F3B166D@eusaamb105.ericsson.se>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn27wH+UQg2e9mhaT385jtph45AOL xeVJbewWLffusVtsPb+K0YHVY8rvjaweO2fdZfdoOfKW1WPJkp9MHjN3zmEKYI3isklJzcks Sy3St0vgyui48YWloIur4n/XXeYGxhecXYycHBICJhJfZrxlh7DFJC7cW8/WxcjFISRwlFFi 7eKtzBDOckaJa89OsYBUsQnoSXyc+hOsQ0QgUKKp9RYziM0skC2x8sp1NhBbWCBL4tySDmaI mmyJc807mSBsK4kbZ66D9bIIqEqsmf0NrJ5XwFfiyKZ5YLaQQKHE1YN7wHo5geYffHUUzGYE uu77qTVMELvEJW49mc8EcbWAxJI955khbFGJl4//sULYShKTlp4DsjmA6jUl1u/Sh2hVlJjS /ZAdYq2gxMmZT1gmMIrNQjJ1FkLHLCQds5B0LGBkWcXIUVqcWpabbmSwiREYX8ck2HR3MO55 aXmIUYCDUYmHdwGbcogQa2JZcWXuIUZpDhYlcd5ZtfOChQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTDOnTar4FbMzI7M3YYvPvXx853/O53JddGmVbEK/Ru3/RWOn7PjX/t1M6a4ln9lTw7k XZl96Py5Zj/eXW7ObyMWRCdJ1vrsvF2953B35OQ7G/+4yD7ln7HMoyD3Wtb298c7S6Y8/lRv d+T6dRVlPmH/u2yW+6dfXDEjJaktrHTPAyv59HNsfyXqlViKMxINtZiLihMBZeOkPpACAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/uxJT59O1DerLhHpoTnx13tQsCCs
Cc: OSPF WG List , Manav Bhatia 
Subject: Re: [OSPF] Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-routable-ip-address-01
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, 25 Sep 2014 17:36:26 -0000

VGhhbmtzIEFjZWUuDQoNCk5vIElQUiBmcm9tIG15IHNpZGUuDQoNCi0tDQpVbWEgQy4NCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFuYXYgQmhhdGlhIFttYWlsdG86bWFu
YXZiaGF0aWFAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQg
OTo1MyBBTQ0KVG86IEFjZWUgTGluZGVtIChhY2VlKQ0KQ2M6IFVtYSBDaHVuZHVyaTsgWGlhb2h1
IFh1OyBNYW5hdiBCaGF0aWE7IE9TUEYgV0cgTGlzdA0KU3ViamVjdDogUmU6IFtPU1BGXSBDYXJy
eWluZyBSb3V0YWJsZSBJUCBBZGRyZXNzZXMgaW4gT1NQRiBSSSBMU0EgLSBkcmFmdC14dS1vc3Bm
LXJvdXRhYmxlLWlwLWFkZHJlc3MtMDENCg0KSGkgQWNlZSwNCg0KTm8gSVBSIGZyb20gbXkgc2lk
ZS4NCg0KV2UnbGwgcHVibGlzaCBpdCBhcyBhIFdHIGRvYyBzb29uLg0KDQpDaGVlcnMsIE1hbmF2
DQoNCk9uIFRodSwgU2VwIDI1LCAyMDE0IGF0IDEwOjAxIFBNLCBBY2VlIExpbmRlbSAoYWNlZSkg
PGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gVW1hLCBYaWFvaHUsIE1hbmF2LA0KPg0KPiBXZSBh
cmUgYWNjZXB0aW5nIHRoaXMgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4gUGxlYXNlIHJlaXNzdWUg
YXMgDQo+IGRyYWZ0LWlldGYteHUtb3NwZi1yb3V0YWJsZS1pcC1hZGRyZXNzLTAwLnR4dC4gQWxz
bywgcGxlYXNlIGluZGljYXRlIA0KPiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFu
eSBJUFIgY2xhaW1zIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0Lg0KPg0KPiBUaGFua3MsDQo+IEFjZWUN
Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
T1NQRiBtYWlsaW5nIGxpc3QNCj4gT1NQRkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCj4NCg==


From nobody Thu Sep 25 12:17:33 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 94EF41A87C7 for ; Thu, 25 Sep 2014 12:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 9xY8dy-BHGUu for ; Thu, 25 Sep 2014 12:17:30 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA951A87B1 for ; Thu, 25 Sep 2014 12:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1411672651; x=1412882251; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=L7FmdBUVRor9eSxn1boYhaDINHC/GwONvFa5BDFlVmY=; b=WiXUVwp7y2mOkY3/YgNMMxDVZLRM9ZK6DArSPP/ByOKTpq00nDqDYyL3 V1ab+V7WZSwjTqtVTPOuHBA6IQ1H6jxUHFPS3ZSOSkE0ERoH5Y8z2V9c6 pHRLUzGNg+Bte+jwJvI9Owa2disASOdBx8dPGvKO8fM3FOq5VoaIZDru+ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjgFAABqJFStJV2Z/2dsb2JhbABggw5TV8pmCodOAoEGFgF7hAQBAQQBAQE1NgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBiDoNwUQBF5AeB4RLAQSLTINahnSHCYFihWuEaYkghAMdLwGCSQEBAQ
X-IronPort-AV: E=Sophos;i="5.04,598,1406592000"; d="scan'208";a="81311564"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 25 Sep 2014 19:17:30 +0000
Received: from [10.21.148.119] (sjc-vpn7-1143.cisco.com [10.21.148.119]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8PJHSqD026494 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Sep 2014 19:17:29 GMT
Message-ID: <54246A47.5060307@cisco.com>
Date: Thu, 25 Sep 2014 12:17:27 -0700
From: Michael Barnes 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Manav Bhatia 
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/ym4EqxnLyGh6QEI_n2wbl-3dGRE
Cc: ospf@ietf.org
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 25 Sep 2014 19:17:31 -0000

Hi Manav,

Perhaps I missed some earlier discussion, on why you decided to add the 
S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be in 
that LSA. I would like to leave the RI LSA with only information 
pertinent to OSPF rather than pollute it with information for which OSPF 
has no interest. If you're concerned with a trend of creating a new 
Opaque type for every application which might want OSPF to carry 
information for it, then I would suggest we create a generic Application 
Information LSA.

Regards,
Michael

On 05/30/2014 01:47 AM, Manav Bhatia wrote:
> Hi,
>
> We had submitted the following draft a couple of weeks ago.
>
> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>
> This draft introduces a new OSPF RI TLV that allows OSPF routers to
> flood the S-BFD discriminator values in the routing domain.
>
> S-BFD is a new charter item (will be approved very soon) in the BFD WG.
>
> Would appreciate comments on this.
>
> Cheers, Manav
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>


From nobody Thu Sep 25 18:27: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 3E1551A00B0 for ; Thu, 25 Sep 2014 18:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 7CilKkiZrhIu for ; Thu, 25 Sep 2014 18:27:27 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EFC1A00F2 for ; Thu, 25 Sep 2014 18:27:27 -0700 (PDT)
Received: by mail-oi0-f42.google.com with SMTP id u20so8992378oif.29 for ; Thu, 25 Sep 2014 18:27:27 -0700 (PDT)
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=kQdpjS4pMOaoCve2mX4zcSxt9X1S/RR2V0vfNw0fD1k=; b=DfUwWaK104ziGslnifHwRgLLAO1avqslNUJFl066of+Vpna18XkVvcBzBFoMkeOvvC UsWJjP3qa0zlYX/8ehO3CZVC5V1R5uIEvt7F0wjMFT/ms78Nl25Q1Je9mjBVa46Plzjn jqiU3WPMM9H+QlElzRVbbZXxHnf2G3HfSMKGDdQIB8c/nCE6fndCIJm9eUpI609pwi6Z hHn9jVKCgOegeA+9birlMI7avgpmng60MzEDM6BYT+J1qRa4XdGAZbYbZb2T1sUIgsn/ mHWDHWCM5suKajzP1iFrWLq0m6JPmOOsynKXcyV87vH3Qi4LcEitRChE+FDT0bUGfW/o /0Ew==
MIME-Version: 1.0
X-Received: by 10.60.134.200 with SMTP id pm8mr6505129oeb.76.1411694846878; Thu, 25 Sep 2014 18:27:26 -0700 (PDT)
Received: by 10.76.13.5 with HTTP; Thu, 25 Sep 2014 18:27:26 -0700 (PDT)
In-Reply-To: <54246A47.5060307@cisco.com>
References:  <54246A47.5060307@cisco.com>
Date: Fri, 26 Sep 2014 06:57:26 +0530
Message-ID: 
From: Manav Bhatia 
To: Michael Barnes 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/CkaWCtUGeWjyULEGEhN-teWha-8
Cc: OSPF - OSPF WG List 
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 26 Sep 2014 01:27:29 -0000

Hi Michael,

Very interesting.

I think there is a disconnect because of our interpretation of what an
RI LSA is envisioned to carry. I assume its meant to advertise
"optional router capabilities" while you believe its to be used solely
for advertising "optional OSPF router capabilities". IMO, limiting the
scope of RI to just OSPF is like using a humvee with all its bells and
whistles to distribute balloons to the children in your friendly
neighborhood park! We wanted a mechanism wherein each router could
proudly tell the world that it was an S-BFD capable node and along
with it also advertise the unique discriminator that the others would
use to reach it. RI we felt, was the perfect tool that we could use
for this purpose.

And btw we're not the first ones to use RI for advertising a router
capability that isnt pertinent to OSPF per se (RFC 5088).

Cheers, Manav

On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes  wrote:
> Hi Manav,
>
> Perhaps I missed some earlier discussion, on why you decided to add the
> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be in that
> LSA. I would like to leave the RI LSA with only information pertinent to
> OSPF rather than pollute it with information for which OSPF has no interest.
> If you're concerned with a trend of creating a new Opaque type for every
> application which might want OSPF to carry information for it, then I would
> suggest we create a generic Application Information LSA.
>
> Regards,
> Michael
>
>
> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>
>> Hi,
>>
>> We had submitted the following draft a couple of weeks ago.
>>
>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>
>> This draft introduces a new OSPF RI TLV that allows OSPF routers to
>> flood the S-BFD discriminator values in the routing domain.
>>
>> S-BFD is a new charter item (will be approved very soon) in the BFD WG.
>>
>> Would appreciate comments on this.
>>
>> Cheers, Manav
>>
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>


From nobody Thu Sep 25 18:50:42 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 767D61A02BD for ; Thu, 25 Sep 2014 18:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 UqMLKWz_CBFj for ; Thu, 25 Sep 2014 18:50:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A70E1A02A2 for ; Thu, 25 Sep 2014 18:50:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNA17882; Fri, 26 Sep 2014 01:50:37 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Sep 2014 02:50:36 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 09:50:30 +0800
From: Xuxiaohu 
To: "Acee Lindem (acee)" , Uma Chunduri , Manav Bhatia 
Thread-Topic: Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-routable-ip-address-01
Thread-Index: AQHP2N4d8MxCsg1MtEO5yO4HvpFm2ZwSpoyA
Date: Fri, 26 Sep 2014 01:50:30 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BBCD6@NKGEML512-MBS.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BBCD6NKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/eMIPSOGPSohawaNeBBCs7KuG7rc
Cc: OSPF WG List 
Subject: Re: [OSPF] Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-routable-ip-address-01
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, 26 Sep 2014 01:50:41 -0000

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BBCD6NKGEML512MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi acee,

I'm not aware of any IPR related to this draft.

Best regards,
Xiaohu

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Friday, September 26, 2014 12:31 AM
To: Uma Chunduri; Xuxiaohu; Manav Bhatia
Cc: OSPF WG List
Subject: Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-ospf-rout=
able-ip-address-01

Uma, Xiaohu, Manav,

We are accepting this draft as a WG document. Please reissue as draft-ietf-=
xu-ospf-routable-ip-address-00.txt. Also, please indicate whether or not yo=
u are aware of any IPR claims related to the draft.

Thanks,
Acee

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BBCD6NKGEML512MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi acee,


 =
;


I’m =
not aware of any IPR related to this draft.


 =
;


Best regar=
ds,


Xiaohu


 =
;






From: Acee Lindem (acee) [mailto:acee@cisco.com]


Sent: Friday, September 26, 2014 12:31 AM

To: Uma Chunduri; Xuxiaohu; Manav Bhatia

Cc: OSPF WG List

Subject: Carrying Routable IP Addresses in OSPF RI LSA - draft-xu-os=
pf-routable-ip-address-01






 




Uma, Xiaohu,=
 Manav, 






 <=
/o:p>






We are accep=
ting this draft as a WG document. Please reissue as draft-ietf-xu-ospf-rout=
able-ip-address-00.txt. Also, please indicate whether or not
 you are aware of any IPR claims related to the draft. 






 <=
/o:p>






Thanks,=







Acee 








--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BBCD6NKGEML512MBSchi_--


From nobody Thu Sep 25 23:24: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 C2A9C1A1A37 for ; Thu, 25 Sep 2014 23:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 DXVX09mI7L3m for ; Thu, 25 Sep 2014 23:24:06 -0700 (PDT)
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 484051A1A1E for ; Thu, 25 Sep 2014 23:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2987; q=dns/txt; s=iport; t=1411712646; x=1412922246; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j36BYhtwuJeuSAXMh1DALspQNph8sTOqBQmk9PN7rro=; b=ejlS8QGH4uFf2Mozu7ZV+8Qu2sFY9oNreEGnuIP9sgZ0Z+x9ofaMxyku mqdWWyFjIkgL1KFniED6dK22Fq1CuQa8bLmFZp9qqxZTdY/csYJY0s36s i1CRkmI1ezJY0VPCIZq8v9oiG5ojYHlTfQkM2FN8iM9TCE+acnsIQeDsm U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FABsGJVStJA2G/2dsb2JhbABggw5TV8otCodOAoEBFgF7hAQBAQQBAQE1NgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBiDoNwUkBF4oqhXQHhEsFi0yDWoZ0hwmBYoVrhGmJIIQDHS8BgkkBAQE
X-IronPort-AV: E=Sophos;i="5.04,603,1406592000"; d="scan'208";a="358383359"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 26 Sep 2014 06:23:52 +0000
Received: from [10.21.95.156] (sjc-vpn5-1948.cisco.com [10.21.95.156]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q6NpP2018790 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 26 Sep 2014 06:23:52 GMT
Message-ID: <54250677.9020606@cisco.com>
Date: Thu, 25 Sep 2014 23:23:51 -0700
From: Michael Barnes 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Manav Bhatia 
References:  <54246A47.5060307@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/KGgvVW2bd6ZUGVajs2mDUGA8MkY
Cc: OSPF - OSPF WG List 
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 26 Sep 2014 06:24:07 -0000

Hi Manav,

That's a pretty funny analogy. I've got another one for you.

Say the RI LSA is like a corporate learjet for a tool company. When it 
gets flown around it's never full so you decide to use it to ship 
wrenches on it along with the executives. You're proud of your wrenches 
and want everyone to know how great they are, but do you really want to 
ship them that way? Maybe it's better to put the wrenches in their own 
vehicle.

So to be a little more serious, if the router wants to proudly proclaim 
its S-BFD capability then it deserves its own special LSA rather than 
being packed into one used for other things.

Cheers,
Michael

On 09/25/2014 06:27 PM, Manav Bhatia wrote:
> Hi Michael,
>
> Very interesting.
>
> I think there is a disconnect because of our interpretation of what an
> RI LSA is envisioned to carry. I assume its meant to advertise
> "optional router capabilities" while you believe its to be used solely
> for advertising "optional OSPF router capabilities". IMO, limiting the
> scope of RI to just OSPF is like using a humvee with all its bells and
> whistles to distribute balloons to the children in your friendly
> neighborhood park! We wanted a mechanism wherein each router could
> proudly tell the world that it was an S-BFD capable node and along
> with it also advertise the unique discriminator that the others would
> use to reach it. RI we felt, was the perfect tool that we could use
> for this purpose.
>
> And btw we're not the first ones to use RI for advertising a router
> capability that isnt pertinent to OSPF per se (RFC 5088).
>
> Cheers, Manav
>
> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes  wrote:
>> Hi Manav,
>>
>> Perhaps I missed some earlier discussion, on why you decided to add the
>> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be in that
>> LSA. I would like to leave the RI LSA with only information pertinent to
>> OSPF rather than pollute it with information for which OSPF has no interest.
>> If you're concerned with a trend of creating a new Opaque type for every
>> application which might want OSPF to carry information for it, then I would
>> suggest we create a generic Application Information LSA.
>>
>> Regards,
>> Michael
>>
>>
>> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>>
>>> Hi,
>>>
>>> We had submitted the following draft a couple of weeks ago.
>>>
>>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>>
>>> This draft introduces a new OSPF RI TLV that allows OSPF routers to
>>> flood the S-BFD discriminator values in the routing domain.
>>>
>>> S-BFD is a new charter item (will be approved very soon) in the BFD WG.
>>>
>>> Would appreciate comments on this.
>>>
>>> Cheers, Manav
>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>
> .
>


From nobody Thu Sep 25 23:35:33 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 AEEDF1A1A32 for ; Thu, 25 Sep 2014 23:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 ehRmKee0FE8G for ; Thu, 25 Sep 2014 23:35:27 -0700 (PDT)
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 2CC6F1A1A26 for ; Thu, 25 Sep 2014 23:35:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2194; q=dns/txt; s=iport; t=1411713327; x=1412922927; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GGeemOM70hcbB8bmRl1WdyLZc1DmOKbZUdNNSzz7SpU=; b=E2zoJKymnBZIDbiVswmuYlREB9fqhnisvhGz93HNjydQRHSYk3kjyo55 Aq1o5YxKo6wA5aEtdpubX6ZXHRCa34E4jOmIv8EUVfzofW0tdbff9Emzl XbXKMNe3Jw9uwEMK3Uje/f/bXn5Lg56cVZIYlAGA2LckRWCnnjSiX8Y8p k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAN8IJVStJA2G/2dsb2JhbABggw5TVwTKKQyHTAKBARYBe4QDAQEBAwEBAQEaUQsFCwIBCA4DAwEBAQEjBAcnCxQJCAIEDgUbiBsIDcFGARMEj2szB4MugR0FkWCEOocJlVaCIIFDbIFIgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,603,1406592000"; d="scan'208";a="81446190"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 26 Sep 2014 06:35:25 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q6ZP6v026795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 06:35:25 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.174]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 01:35:25 -0500
From: "Stefano Previdi (sprevidi)" 
To: Alia Atlas 
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP2Ek7i4SgSSVd1EqvE6Ot46My35wSNQ8AgAAE9oCAARFRgA==
Date: Fri, 26 Sep 2014 06:35:24 +0000
Message-ID: 
References:   <3f9f2001bb53497bbfe258bb3b0b0dbc@DM2PR05MB573.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.194.42]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <0F5C29EAC4E8BE4499B380ED7A7888C7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/RELhngcnST54kDADK5Toc0uxvJg
Cc: Spencer Giacalone , OSPF List , Alia Atlas , "David Ward \(wardd\)" 
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
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, 26 Sep 2014 06:35:28 -0000

I'm not aware of any IPR.

s.


On Sep 25, 2014, at 4:17 PM, Alia Atlas wrote:

> I am also not aware of any other IPR.
>=20
> Alia
>=20
> On Sep 25, 2014 9:59 AM, "John E Drake"  wrote:
> I am not aware of any IPR.
>=20
> =20
>=20
> Yours Irrespectively,
>=20
> =20
>=20
> John
>=20
> =20
>=20
> From: Acee Lindem (acee) [mailto:acee@cisco.com]=20
> Sent: Wednesday, September 24, 2014 3:45 PM
> To: OSPF WG List; David Ward (wardd); Stefano Previdi (sprevidi); John E =
Drake; Alia Atlas; Spencer Giacalone
> Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering =
(TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
>=20
> =20
>=20
> This subject draft in WG last call has this IPR statement:=20
>=20
> =20
>=20
> https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddr=
aft-ietf-ospf-te-metric-extensions
>=20
> =20
>=20
> Authors =96 please indicate whether or not you are aware of any other IPR=
.=20
>=20
> =20
>=20
> Thanks,
>=20
> Acee
>=20
> =20
>=20
> From: Acee Lindem 
> Date: Friday, September 19, 2014 at 1:49 PM
> To: OSPF WG List , "draft-ietf-ospf-te-metric-extensions@t=
ools.ietf.org" 
> Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE)=
 Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
>=20
> =20
>=20
> =20
>=20
> After more than 3 years of discussion and revision, the chairs feel that =
we are ready for a WG last call on the OSPF TE Metric extensions. While it =
is only one piece of an end-to-end delay/loss aware routing solution, we be=
lieve that the draft, as scoped, is ready. The WG last call will end at 12:=
00 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:=20
>=20
> =20
>=20
> https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/
>=20
> =20
>=20
> Thanks,
>=20
> Acee and Abhay=20
>=20
> =20
>=20
>=20
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>=20


From nobody Thu Sep 25 23:58:31 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 2225F1A1A50 for ; Thu, 25 Sep 2014 23:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 c6nk-9OimkyP for ; Thu, 25 Sep 2014 23:58:26 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9CF1A1A49 for ; Thu, 25 Sep 2014 23:58:25 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id l13so9860871iga.0 for ; Thu, 25 Sep 2014 23:58:24 -0700 (PDT)
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=4miV2VA0wUDFHiLoj/cLBY5aYm8bPESOq02HbkZR4f0=; b=F8hJ/Sh0OQEbWo6vLVTzQdCcavFdB76F8VO1w6Av/+LCxLKCgqoiS8kgS0UPMkucU1 fpl7cY95fok5NhsMWruvLeOCEqcuHpKh5nfYleU2xPOr9DOXv/mao+0LGt8tkpO5WBZO Jn+HxwQIVAHYAfdttIPgQdJ8ogS2D9SJOqGhYjB9CR1C+czS0igfc2XdCGoH1we/kyVW 66NjTwIGuj6f53HbbZLalH8+48ELH8F7bYpeFHg+z8nGKqp9QvedY3BUQh9mYGTg53qe eizlpRL4mvoDn3bHrX47IDOKrpEQXP748Js3gNQLiXa4iN61vNewlfSWke7yqghNDLU9 kgwQ==
MIME-Version: 1.0
X-Received: by 10.42.114.130 with SMTP id g2mr18423593icq.46.1411714704386; Thu, 25 Sep 2014 23:58:24 -0700 (PDT)
Received: by 10.107.165.204 with HTTP; Thu, 25 Sep 2014 23:58:24 -0700 (PDT)
In-Reply-To: <54250677.9020606@cisco.com>
References:  <54246A47.5060307@cisco.com>  <54250677.9020606@cisco.com>
Date: Fri, 26 Sep 2014 12:28:24 +0530
Message-ID: 
From: Manav Bhatia 
To: Michael Barnes 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/83UNC0MyLXyXmJZPx_AOI9nymWI
Cc: OSPF - OSPF WG List 
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 26 Sep 2014 06:58:29 -0000

Hi Michael,

:-)

Lets not deal with analogies (my bad!) lest we get misled by those.

Clearly you and I look at RI LSAs differently. I dont think what youre
suggesting is even remotely preposterous. However, i do believe that
RIs can serve more than merely announcing OSPF specific router
capabilities.

And once again, we already have a precedent where RI was used for
announcing non OSPF specific capability -- which means that the
co-authors of this draft arent the only ones who think of RIs as being
a generic tool for router capability advertisement.

Lets hear what others have to say on this.

Cheers, Manav


On Fri, Sep 26, 2014 at 11:53 AM, Michael Barnes  wrote:
> Hi Manav,
>
> That's a pretty funny analogy. I've got another one for you.
>
> Say the RI LSA is like a corporate learjet for a tool company. When it gets
> flown around it's never full so you decide to use it to ship wrenches on it
> along with the executives. You're proud of your wrenches and want everyone
> to know how great they are, but do you really want to ship them that way?
> Maybe it's better to put the wrenches in their own vehicle.
>
> So to be a little more serious, if the router wants to proudly proclaim its
> S-BFD capability then it deserves its own special LSA rather than being
> packed into one used for other things.
>
> Cheers,
> Michael
>
>
> On 09/25/2014 06:27 PM, Manav Bhatia wrote:
>>
>> Hi Michael,
>>
>> Very interesting.
>>
>> I think there is a disconnect because of our interpretation of what an
>> RI LSA is envisioned to carry. I assume its meant to advertise
>> "optional router capabilities" while you believe its to be used solely
>> for advertising "optional OSPF router capabilities". IMO, limiting the
>> scope of RI to just OSPF is like using a humvee with all its bells and
>> whistles to distribute balloons to the children in your friendly
>> neighborhood park! We wanted a mechanism wherein each router could
>> proudly tell the world that it was an S-BFD capable node and along
>> with it also advertise the unique discriminator that the others would
>> use to reach it. RI we felt, was the perfect tool that we could use
>> for this purpose.
>>
>> And btw we're not the first ones to use RI for advertising a router
>> capability that isnt pertinent to OSPF per se (RFC 5088).
>>
>> Cheers, Manav
>>
>> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes 
>> wrote:
>>>
>>> Hi Manav,
>>>
>>> Perhaps I missed some earlier discussion, on why you decided to add the
>>> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be in
>>> that
>>> LSA. I would like to leave the RI LSA with only information pertinent to
>>> OSPF rather than pollute it with information for which OSPF has no
>>> interest.
>>> If you're concerned with a trend of creating a new Opaque type for every
>>> application which might want OSPF to carry information for it, then I
>>> would
>>> suggest we create a generic Application Information LSA.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> We had submitted the following draft a couple of weeks ago.
>>>>
>>>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>>>
>>>> This draft introduces a new OSPF RI TLV that allows OSPF routers to
>>>> flood the S-BFD discriminator values in the routing domain.
>>>>
>>>> S-BFD is a new charter item (will be approved very soon) in the BFD WG.
>>>>
>>>> Would appreciate comments on this.
>>>>
>>>> Cheers, Manav
>>>>
>>>>
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> OSPF@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>
>>>
>> .
>>
>


From nobody Fri Sep 26 01:10: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 33CEC1A1AA0 for ; Fri, 26 Sep 2014 01:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level: 
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, 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 TZLMZ46SgsIX for ; Fri, 26 Sep 2014 01:09:55 -0700 (PDT)
Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBA81A1A9D for ; Fri, 26 Sep 2014 01:08:52 -0700 (PDT)
Received: from [10.43.66.140] (194.163.249.24) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 2675EE; Fri, 26 Sep 2014 10:08:42 +0200
Message-ID: <54251F08.7060502@linfre.de>
Date: Fri, 26 Sep 2014 10:08:40 +0200
From: Karsten Thomann 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Manav Bhatia 
References:  <54246A47.5060307@cisco.com>  <54250677.9020606@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 4
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/vhxFW3sM8nTdSl0bADsNAwD4j5M
Cc: OSPF - OSPF WG List 
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 26 Sep 2014 08:10:00 -0000

Hi,

RFC 4970 Section 3 includes:

    The purpose of the Router Information (RI) LSA is to advertise
    information relating to the aggregate OSPF router.  Normally, this
    should be confined to TLVs with a single value or very few values.
    It is not meant to be a generic container to carry any and all
    information.

I think the first sentence allows it, as it is related to the ospf router,
even if it is not an ospf internal information.
Michael is right that not everything should be in the RI LSA as already
mentioned in the RFC, increasing the count of LSAs which need to be
flooded across the domain has also drawbacks in term of scalability.

Regards,

Karsten


Am 26.09.2014 08:58, schrieb Manav Bhatia:
> Hi Michael,
>
> :-)
>
> Lets not deal with analogies (my bad!) lest we get misled by those.
>
> Clearly you and I look at RI LSAs differently. I dont think what youre
> suggesting is even remotely preposterous. However, i do believe that
> RIs can serve more than merely announcing OSPF specific router
> capabilities.
>
> And once again, we already have a precedent where RI was used for
> announcing non OSPF specific capability -- which means that the
> co-authors of this draft arent the only ones who think of RIs as being
> a generic tool for router capability advertisement.
>
> Lets hear what others have to say on this.
>
> Cheers, Manav
>
>
> On Fri, Sep 26, 2014 at 11:53 AM, Michael Barnes  wrote:
>> Hi Manav,
>>
>> That's a pretty funny analogy. I've got another one for you.
>>
>> Say the RI LSA is like a corporate learjet for a tool company. When it gets
>> flown around it's never full so you decide to use it to ship wrenches on it
>> along with the executives. You're proud of your wrenches and want everyone
>> to know how great they are, but do you really want to ship them that way?
>> Maybe it's better to put the wrenches in their own vehicle.
>>
>> So to be a little more serious, if the router wants to proudly proclaim its
>> S-BFD capability then it deserves its own special LSA rather than being
>> packed into one used for other things.
>>
>> Cheers,
>> Michael
>>
>>
>> On 09/25/2014 06:27 PM, Manav Bhatia wrote:
>>> Hi Michael,
>>>
>>> Very interesting.
>>>
>>> I think there is a disconnect because of our interpretation of what an
>>> RI LSA is envisioned to carry. I assume its meant to advertise
>>> "optional router capabilities" while you believe its to be used solely
>>> for advertising "optional OSPF router capabilities". IMO, limiting the
>>> scope of RI to just OSPF is like using a humvee with all its bells and
>>> whistles to distribute balloons to the children in your friendly
>>> neighborhood park! We wanted a mechanism wherein each router could
>>> proudly tell the world that it was an S-BFD capable node and along
>>> with it also advertise the unique discriminator that the others would
>>> use to reach it. RI we felt, was the perfect tool that we could use
>>> for this purpose.
>>>
>>> And btw we're not the first ones to use RI for advertising a router
>>> capability that isnt pertinent to OSPF per se (RFC 5088).
>>>
>>> Cheers, Manav
>>>
>>> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes 
>>> wrote:
>>>> Hi Manav,
>>>>
>>>> Perhaps I missed some earlier discussion, on why you decided to add the
>>>> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be in
>>>> that
>>>> LSA. I would like to leave the RI LSA with only information pertinent to
>>>> OSPF rather than pollute it with information for which OSPF has no
>>>> interest.
>>>> If you're concerned with a trend of creating a new Opaque type for every
>>>> application which might want OSPF to carry information for it, then I
>>>> would
>>>> suggest we create a generic Application Information LSA.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> We had submitted the following draft a couple of weeks ago.
>>>>>
>>>>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>>>>
>>>>> This draft introduces a new OSPF RI TLV that allows OSPF routers to
>>>>> flood the S-BFD discriminator values in the routing domain.
>>>>>
>>>>> S-BFD is a new charter item (will be approved very soon) in the BFD WG.
>>>>>
>>>>> Would appreciate comments on this.
>>>>>
>>>>> Cheers, Manav
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OSPF mailing list
>>>>> OSPF@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>
>>> .
>>>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf


From nobody Fri Sep 26 02: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 567D61A1AAA for ; Fri, 26 Sep 2014 02:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 3cncnYfNx9bI for ; Fri, 26 Sep 2014 02:08:32 -0700 (PDT)
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 742DB1A1A54 for ; Fri, 26 Sep 2014 02:08:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5751; q=dns/txt; s=iport; t=1411722513; x=1412932113; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=40ZH5LdO09WH5a4tHakajXu1yHtO92HxcgUict/m3RM=; b=Odg2ihSuprDHinu7+WBFg4vkL7nVcTrxERI1P94hxWB5XCbRFdGkXX2V GuXDDI3+/70jFNS+epU8afTNou2YKmYeuqPtKkwC3dtAZt233OiI5J4Di 833ScFyX/U2cV/ZuBDnKZLvIhXsJ0S8nOPKD39sSmhripAclSZDpOatW9 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAEgsJVStJA2I/2dsb2JhbABggmsjU1cEyjMKh04CgQQWAXuEAwEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FiDYIAQzAdgEXiiqFETAzB4MugR0FjykighiEOocJgWKKWIkgg2NsAYFHgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,603,1406592000"; d="scan'208";a="81480353"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 26 Sep 2014 09:08:32 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q98V3V017311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 09:08:31 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 04:08:31 -0500
From: "Carlos Pignataro (cpignata)" 
To: Karsten Thomann 
Thread-Topic: [OSPF] Advertising S-BFD discriminators in OSPF
Thread-Index: AQHP2PVhGay6guaisE2mpkzmQOEuupwS8/UAgABS0oCAAAmnAIAAE6IAgAAQuAA=
Date: Fri, 26 Sep 2014 09:08:30 +0000
Message-ID: 
References:  <54246A47.5060307@cisco.com>  <54250677.9020606@cisco.com>  <54251F08.7060502@linfre.de>
In-Reply-To: <54251F08.7060502@linfre.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.87.159]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <594929322B002E4CA29B43E930B620B3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/1MsZoDKm_zGG86qEy_2EjvJBnFw
Cc: OSPF - OSPF WG List 
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 26 Sep 2014 09:08:34 -0000

Michael,

That first sentence quoted below has the key -- Basically, the S-BFD discri=
minator is tied to the node. It is an RI piece, with very a very small amou=
nt of data. Further, it is information that relates directly to OSPF, as IG=
Ps are clients and users of S-BFD. It is not OSPF data per se, you are corr=
ect, but it is a "information relating to the aggregate OSPF router".

Thanks,

Carlos.

On Sep 26, 2014, at 9:08 AM, Karsten Thomann  wr=
ote:

> Hi,
>=20
> RFC 4970 Section 3 includes:
>=20
>   The purpose of the Router Information (RI) LSA is to advertise
>   information relating to the aggregate OSPF router.  Normally, this
>   should be confined to TLVs with a single value or very few values.
>   It is not meant to be a generic container to carry any and all
>   information.
>=20
> I think the first sentence allows it, as it is related to the ospf router=
,
> even if it is not an ospf internal information.
> Michael is right that not everything should be in the RI LSA as already
> mentioned in the RFC, increasing the count of LSAs which need to be
> flooded across the domain has also drawbacks in term of scalability.
>=20
> Regards,
>=20
> Karsten
>=20
>=20
> Am 26.09.2014 08:58, schrieb Manav Bhatia:
>> Hi Michael,
>>=20
>> :-)
>>=20
>> Lets not deal with analogies (my bad!) lest we get misled by those.
>>=20
>> Clearly you and I look at RI LSAs differently. I dont think what youre
>> suggesting is even remotely preposterous. However, i do believe that
>> RIs can serve more than merely announcing OSPF specific router
>> capabilities.
>>=20
>> And once again, we already have a precedent where RI was used for
>> announcing non OSPF specific capability -- which means that the
>> co-authors of this draft arent the only ones who think of RIs as being
>> a generic tool for router capability advertisement.
>>=20
>> Lets hear what others have to say on this.
>>=20
>> Cheers, Manav
>>=20
>>=20
>> On Fri, Sep 26, 2014 at 11:53 AM, Michael Barnes  wr=
ote:
>>> Hi Manav,
>>>=20
>>> That's a pretty funny analogy. I've got another one for you.
>>>=20
>>> Say the RI LSA is like a corporate learjet for a tool company. When it =
gets
>>> flown around it's never full so you decide to use it to ship wrenches o=
n it
>>> along with the executives. You're proud of your wrenches and want every=
one
>>> to know how great they are, but do you really want to ship them that wa=
y?
>>> Maybe it's better to put the wrenches in their own vehicle.
>>>=20
>>> So to be a little more serious, if the router wants to proudly proclaim=
 its
>>> S-BFD capability then it deserves its own special LSA rather than being
>>> packed into one used for other things.
>>>=20
>>> Cheers,
>>> Michael
>>>=20
>>>=20
>>> On 09/25/2014 06:27 PM, Manav Bhatia wrote:
>>>> Hi Michael,
>>>>=20
>>>> Very interesting.
>>>>=20
>>>> I think there is a disconnect because of our interpretation of what an
>>>> RI LSA is envisioned to carry. I assume its meant to advertise
>>>> "optional router capabilities" while you believe its to be used solely
>>>> for advertising "optional OSPF router capabilities". IMO, limiting the
>>>> scope of RI to just OSPF is like using a humvee with all its bells and
>>>> whistles to distribute balloons to the children in your friendly
>>>> neighborhood park! We wanted a mechanism wherein each router could
>>>> proudly tell the world that it was an S-BFD capable node and along
>>>> with it also advertise the unique discriminator that the others would
>>>> use to reach it. RI we felt, was the perfect tool that we could use
>>>> for this purpose.
>>>>=20
>>>> And btw we're not the first ones to use RI for advertising a router
>>>> capability that isnt pertinent to OSPF per se (RFC 5088).
>>>>=20
>>>> Cheers, Manav
>>>>=20
>>>> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes 
>>>> wrote:
>>>>> Hi Manav,
>>>>>=20
>>>>> Perhaps I missed some earlier discussion, on why you decided to add t=
he
>>>>> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be i=
n
>>>>> that
>>>>> LSA. I would like to leave the RI LSA with only information pertinent=
 to
>>>>> OSPF rather than pollute it with information for which OSPF has no
>>>>> interest.
>>>>> If you're concerned with a trend of creating a new Opaque type for ev=
ery
>>>>> application which might want OSPF to carry information for it, then I
>>>>> would
>>>>> suggest we create a generic Application Information LSA.
>>>>>=20
>>>>> Regards,
>>>>> Michael
>>>>>=20
>>>>>=20
>>>>> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> We had submitted the following draft a couple of weeks ago.
>>>>>>=20
>>>>>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>>>>>=20
>>>>>> This draft introduces a new OSPF RI TLV that allows OSPF routers to
>>>>>> flood the S-BFD discriminator values in the routing domain.
>>>>>>=20
>>>>>> S-BFD is a new charter item (will be approved very soon) in the BFD =
WG.
>>>>>>=20
>>>>>> Would appreciate comments on this.
>>>>>>=20
>>>>>> Cheers, Manav
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OSPF mailing list
>>>>>> OSPF@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>=20
>>>> .
>>>>=20
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>=20
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf


From nobody Fri Sep 26 04:49: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 4FA571A1B3A for ; Fri, 26 Sep 2014 04:49:28 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Ahb85jxgF-OQ for ; Fri, 26 Sep 2014 04:49:26 -0700 (PDT)
Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8151A1B16 for ; Fri, 26 Sep 2014 04:49:26 -0700 (PDT)
Received: from [65.190.6.125] ([65.190.6.125:48421] helo=[10.0.1.6]) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id F6/68-14464-5C255245; Fri, 26 Sep 2014 11:49:25 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Acee Lindem 
In-Reply-To: <54251F08.7060502@linfre.de>
Date: Fri, 26 Sep 2014 07:49:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54246A47.5060307@cisco.com>  <54250677.9020606@cisco.com>  <54251F08.7060502@linfre.de>
To: Karsten Thomann , Michael J Barnes 
X-Mailer: Apple Mail (2.1878.6)
X-RR-Connecting-IP: 107.14.168.130:25
X-Cloudmark-Score: 0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Cy8qKQkVZXBZrY54wrOoIAi62SU
Cc: OSPF List 
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 26 Sep 2014 11:49:28 -0000

Hi Michael, Manav, Karsten,=20

We did have this discussion back when we put the first piece of non-OSPF =
information in the OSPF RI LSA and conceded that the OSPF RI LSA could =
be used for all types of information.

https://datatracker.ietf.org/doc/rfc5088/

On the same subject, I have further conceded that this will be used for =
variable length information and am doing a bis version of the RFC4970 =
accommodating multiple instance of the RI LSA. I will be presenting the =
updates in Honolulu.=20

https://datatracker.ietf.org/doc/draft-acee-ospf-rfc4970bis/

Thanks,
Acee
P.S. I=92m glad I didn=92t reply last night - we might have missed out =
on all the analogies ;^).=20


On Sep 26, 2014, at 4:08 AM, Karsten Thomann  =
wrote:

> Hi,
>=20
> RFC 4970 Section 3 includes:
>=20
>   The purpose of the Router Information (RI) LSA is to advertise
>   information relating to the aggregate OSPF router.  Normally, this
>   should be confined to TLVs with a single value or very few values.
>   It is not meant to be a generic container to carry any and all
>   information.
>=20
> I think the first sentence allows it, as it is related to the ospf =
router,
> even if it is not an ospf internal information.
> Michael is right that not everything should be in the RI LSA as =
already
> mentioned in the RFC, increasing the count of LSAs which need to be
> flooded across the domain has also drawbacks in term of scalability.
>=20
> Regards,
>=20
> Karsten
>=20
>=20
> Am 26.09.2014 08:58, schrieb Manav Bhatia:
>> Hi Michael,
>>=20
>> :-)
>>=20
>> Lets not deal with analogies (my bad!) lest we get misled by those.
>>=20
>> Clearly you and I look at RI LSAs differently. I dont think what =
youre
>> suggesting is even remotely preposterous. However, i do believe that
>> RIs can serve more than merely announcing OSPF specific router
>> capabilities.
>>=20
>> And once again, we already have a precedent where RI was used for
>> announcing non OSPF specific capability -- which means that the
>> co-authors of this draft arent the only ones who think of RIs as =
being
>> a generic tool for router capability advertisement.
>>=20
>> Lets hear what others have to say on this.
>>=20
>> Cheers, Manav
>>=20
>>=20
>> On Fri, Sep 26, 2014 at 11:53 AM, Michael Barnes  =
wrote:
>>> Hi Manav,
>>>=20
>>> That's a pretty funny analogy. I've got another one for you.
>>>=20
>>> Say the RI LSA is like a corporate learjet for a tool company. When =
it gets
>>> flown around it's never full so you decide to use it to ship =
wrenches on it
>>> along with the executives. You're proud of your wrenches and want =
everyone
>>> to know how great they are, but do you really want to ship them that =
way?
>>> Maybe it's better to put the wrenches in their own vehicle.
>>>=20
>>> So to be a little more serious, if the router wants to proudly =
proclaim its
>>> S-BFD capability then it deserves its own special LSA rather than =
being
>>> packed into one used for other things.
>>>=20
>>> Cheers,
>>> Michael
>>>=20
>>>=20
>>> On 09/25/2014 06:27 PM, Manav Bhatia wrote:
>>>> Hi Michael,
>>>>=20
>>>> Very interesting.
>>>>=20
>>>> I think there is a disconnect because of our interpretation of what =
an
>>>> RI LSA is envisioned to carry. I assume its meant to advertise
>>>> "optional router capabilities" while you believe its to be used =
solely
>>>> for advertising "optional OSPF router capabilities". IMO, limiting =
the
>>>> scope of RI to just OSPF is like using a humvee with all its bells =
and
>>>> whistles to distribute balloons to the children in your friendly
>>>> neighborhood park! We wanted a mechanism wherein each router could
>>>> proudly tell the world that it was an S-BFD capable node and along
>>>> with it also advertise the unique discriminator that the others =
would
>>>> use to reach it. RI we felt, was the perfect tool that we could use
>>>> for this purpose.
>>>>=20
>>>> And btw we're not the first ones to use RI for advertising a router
>>>> capability that isnt pertinent to OSPF per se (RFC 5088).
>>>>=20
>>>> Cheers, Manav
>>>>=20
>>>> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes =

>>>> wrote:
>>>>> Hi Manav,
>>>>>=20
>>>>> Perhaps I missed some earlier discussion, on why you decided to =
add the
>>>>> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not =
be in
>>>>> that
>>>>> LSA. I would like to leave the RI LSA with only information =
pertinent to
>>>>> OSPF rather than pollute it with information for which OSPF has no
>>>>> interest.
>>>>> If you're concerned with a trend of creating a new Opaque type for =
every
>>>>> application which might want OSPF to carry information for it, =
then I
>>>>> would
>>>>> suggest we create a generic Application Information LSA.
>>>>>=20
>>>>> Regards,
>>>>> Michael
>>>>>=20
>>>>>=20
>>>>> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> We had submitted the following draft a couple of weeks ago.
>>>>>>=20
>>>>>> =
http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>>>>>=20
>>>>>> This draft introduces a new OSPF RI TLV that allows OSPF routers =
to
>>>>>> flood the S-BFD discriminator values in the routing domain.
>>>>>>=20
>>>>>> S-BFD is a new charter item (will be approved very soon) in the =
BFD WG.
>>>>>>=20
>>>>>> Would appreciate comments on this.
>>>>>>=20
>>>>>> Cheers, Manav
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OSPF mailing list
>>>>>> OSPF@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>=20
>>>> .
>>>>=20
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>=20
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf


From nobody Fri Sep 26 05:08: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 A7F3E1A1B68; Fri, 26 Sep 2014 05:08:09 -0700 (PDT)
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 ygBZA1K314uF; Fri, 26 Sep 2014 05:08:07 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32671A1B3D; Fri, 26 Sep 2014 05:08:07 -0700 (PDT)
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 26 Sep 2014 12:08:06 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1039.011; Fri, 26 Sep 2014 12:08:06 +0000
From: John E Drake 
To: "rtg-ads@tools.ietf.org" 
Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ospf-bfd-discriminator-00.txt
Thread-Index: Ac/ZgP9Z/cIFEsLbSMmxt7VD3T5ggw==
Date: Fri, 26 Sep 2014 12:08:05 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB562;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(90102001)(83072002)(20776003)(83322001)(10300001)(99396003)(120916001)(19580395003)(33646002)(85852003)(21056001)(92566001)(86362001)(64706001)(54356999)(105586002)(50986999)(2351001)(4396001)(229853001)(95666004)(108616004)(230783001)(99286002)(87936001)(106356001)(2656002)(110136001)(85306004)(79102003)(77982003)(101416001)(66066001)(46102003)(74662003)(80022003)(74502003)(74316001)(81542003)(81342003)(76482002)(107046002)(15975445006)(76576001)(31966008)(97736003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; 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/ejeNzgj_Lm_SG9w_yWRP9Yfz6x0
Cc: "rtg-dir@ietf.org" , "draft-ietf-ospf-bfd-discriminator.all@ietf.org" , OSPF WG List 
Subject: [OSPF] [RTG-DIR] RtgDir review: draft-ietf-ospf-bfd-discriminator-00.txt
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, 26 Sep 2014 12:08:09 -0000

Hi

I've been selected as the routing directorate QA reviewer for draft-ietf-os=
pf-bfd-discriminator-00. This is part of the QA process described at https:=
//trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa                       =
                   =20

The document is in good shape.  It is very readable and I don't see any iss=
ues with it.=20

Yours Irrespectively,

John


From nobody Fri Sep 26 07:11: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 386731A8897; Fri, 26 Sep 2014 07:10:49 -0700 (PDT)
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 hzRxc25ng86w; Fri, 26 Sep 2014 07:10:47 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7E91A6FA9; Fri, 26 Sep 2014 07:10:46 -0700 (PDT)
Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB289.namprd05.prod.outlook.com (10.141.23.19) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 26 Sep 2014 14:10:44 +0000
Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.1039.011; Fri, 26 Sep 2014 14:10:44 +0000
From: Chris Bowers 
To: "spring@ietf.org" , "isis-wg@ietf.org" , "ospf@ietf.org" 
Thread-Topic: New Version Notification for draft-bowers-spring-advertising-lsps-with-sr-00.txt
Thread-Index: AQHP2OvQFL5Yiqc+HkqeM+vB/XjqmZwTYirA
Date: Fri, 26 Sep 2014 14:10:44 +0000
Message-ID: <82ba0346d2de44b7ac3533328012fa7d@BLUPR05MB292.namprd05.prod.outlook.com>
References: <20140925180907.27662.88544.idtracker@ietfa.amsl.com>
In-Reply-To: <20140925180907.27662.88544.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.239.11]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB289;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(199003)(377454003)(377424004)(189002)(13464003)(83322001)(2201001)(19580395003)(19580405001)(92566001)(101416001)(76482002)(105586002)(106116001)(31966008)(85306004)(64706001)(4396001)(15202345003)(86362001)(79102003)(81542003)(81342003)(74662003)(80022003)(120916001)(66066001)(46102003)(20776003)(95666004)(74502003)(10300001)(87936001)(85852003)(108616004)(77982003)(99286002)(107046002)(83072002)(107886001)(15975445006)(99396003)(2656002)(54356999)(230783001)(76176999)(2501002)(21056001)(74316001)(76576001)(50986999)(97736003)(33646002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB289; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/N_zTrEAcLzshjsa2EHI5jkJBjwI
Subject: [OSPF] FW: New Version Notification for draft-bowers-spring-advertising-lsps-with-sr-00.txt
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, 26 Sep 2014 14:10:49 -0000

VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc2V2ZXJhbCB1c2UgY2FzZXMgZm9yIHVzaW5nIHNlZ21l
bnQgcm91dGluZyB0byBhZHZlcnRpc2UgbGFiZWwgYmluZGluZ3MgY29ycmVzcG9uZGluZyB0byBM
U1BzLg0KDQpBdCB0aGUgSVNJUyBXRyBtZWV0aW5nIGluIFRvcm9udG8gYXMgd2VsbCBhcyBmb2xs
b3ctdXAgZGlzY3Vzc2lvbiBvbiB0aGUgSVNJUyBhbmQgU1BSSU5HIGxpc3RzLCBzZXZlcmFsIHBl
b3BsZSBhZ3JlZWQgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgc2VwYXJhdGUgKG9yIGFkZGl0
aW9uYWwpIGRvY3VtZW50IGluIHRoZSBTUFJJTkcgV0cgY292ZXJpbmcgQmluZGluZyBUTFYgdXNl
IGNhc2VzIHRoYXQgY2FuIHJlZmVyZW5jZWQgZnJvbSBib3RoIElTSVMgYW5kIE9TUEYgcHJvdG9j
b2wgZXh0ZW5zaW9ucyBkb2N1bWVudHMsIGluIG9yZGVyIHRvIGFsbG93IHRoZSBwcm90b2NvbCBl
eHRlbnNpb25zIGRvY3VtZW50cyB0byBmb2N1cyBvbiBiaXRzIGFuZCBieXRlcy4NCg0KVGhpcyBk
b2N1bWVudCBpcyBhbiBhdHRlbXB0IHRvIGFkZHJlc3MgdGhhdCBuZWVkLiAgQ29tbWVudHMgYXJl
IHdlbGNvbWUuDQoNCkNocmlzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp
bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd
IA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCAxOjA5IFBNDQpUbzogVW1hIENo
dW5kdXJpOyBIYW5uZXMgR3JlZGxlcjsgQ2hyaXMgQm93ZXJzOyBDaHJpcyBCb3dlcnM7IFVtYSBD
aHVuZHVyaTsgSGFubmVzIEdyZWRsZXINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv
biBmb3IgZHJhZnQtYm93ZXJzLXNwcmluZy1hZHZlcnRpc2luZy1sc3BzLXdpdGgtc3ItMDAudHh0
DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJvd2Vycy1zcHJpbmctYWR2ZXJ0aXNp
bmctbHNwcy13aXRoLXNyLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi
eSBDaHJpcyBCb3dlcnMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l
OgkJZHJhZnQtYm93ZXJzLXNwcmluZy1hZHZlcnRpc2luZy1sc3BzLXdpdGgtc3INClJldmlzaW9u
OgkwMA0KVGl0bGU6CQlBZHZlcnRpc2luZyBMU1BzIHdpdGggU2VnbWVudCBSb3V0aW5nDQpEb2N1
bWVudCBkYXRlOgkyMDE0LTA5LTI1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn
ZXM6CQkxNA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh
ZnRzL2RyYWZ0LWJvd2Vycy1zcHJpbmctYWR2ZXJ0aXNpbmctbHNwcy13aXRoLXNyLTAwLnR4dA0K
U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJv
d2Vycy1zcHJpbmctYWR2ZXJ0aXNpbmctbHNwcy13aXRoLXNyLw0KSHRtbGl6ZWQ6ICAgICAgIGh0
dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvd2Vycy1zcHJpbmctYWR2ZXJ0aXNpbmct
bHNwcy13aXRoLXNyLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IHJvdXRpbmcgdXNlcyBn
bG9iYWxseS1rbm93biBsYWJlbHMgdG8gYWNjb21wbGlzaCBmb3J3YXJkaW5nDQogICBhbG9uZyBz
aG9ydGVzdCBwYXRocywgYW5kIGxhYmVsIHN0YWNrcyB0byBhY2NvbXBsaXNoIGV4cGxpY2l0IHJv
dXRpbmcNCiAgIGFsb25nIGFyYml0cmFyeSBwYXRocy4gIFRoZXNlIGxhYmVscyBhcmUgYWR2ZXJ0
aXNlZCB1c2luZyBhbiBJR1AuDQogICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyBob3cgbGFiZWwgYmlu
ZGluZ3MgY29ycmVzcG9uZGluZyB0byBSU1ZQLCBMRFAsDQogICBCR1AgbGFiZWxlZC11bmljYXN0
LCBhbmQgc3RhdGljIExTUHMgYXJlIGFkdmVydGlzZWQgaW4gc2VnbWVudA0KICAgcm91dGluZyBh
bmQgaG93IHRoZXNlIGxhYmVscyBjYW4gYmUgY29tYmluZWQgd2l0aCBvdGhlciBzZWdtZW50DQog
ICByb3V0aW5nIGxhYmVscyB0byBjcmVhdGUgZm9yd2FyZGluZyBwYXRocy4gIFRoaXMgZHJhZnQg
YWxzbyBkZXNjcmliZXMNCiAgIGhvdyBjb250ZXh0IGxhYmVscyBmb3IgZWdyZXNzIG5vZGUgcHJv
dGVjdGlvbiBhcmUgYWR2ZXJ0aXNlZCBpbiB1c2luZw0KICAgc2VnbWVudCByb3V0aW5nIElHUCBl
eHRlbnNpb25zLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg
dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi
bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl
IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Fri Sep 26 07:12:33 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 F19AF1A88D2 for ; Fri, 26 Sep 2014 07:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 TOGXv7gpa5_I for ; Fri, 26 Sep 2014 07:12:29 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD731A886F for ; Fri, 26 Sep 2014 07:12:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6234; q=dns/txt; s=iport; t=1411740749; x=1412950349; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KBqCfKsNq8Nb/0UGgiqDIn/4t+qCdV86hgsJt6HSm70=; b=gwdS9mj2UB7HEkdO0VEn79t6p0JJMI515qgiF3vg4q6DpyOSeJX64uAB yviNLznjNqURGHYeIVaPOQe319VIPv2nNCSVTLjbu7C30JHZ/uQO0rhv6 u7cjQkSKoeWxT3tPPw9d8QvBl5IdK7FD8SIQx615+qpfAfgjRUlEwGmxY w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FABBzJVStJV2b/2dsb2JhbABggw5TV8o/CodOAoEHFgF7hAQBAQQBAQEvAQU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIOg2/eQEXiiqFEWMHhEsBBIRhhm6DWoZ0hDiCUYFihW+EaYkghAMdLwGCSQEBAQ
X-IronPort-AV: E=Sophos;i="5.04,604,1406592000"; d="scan'208";a="358428356"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2014 14:12:27 +0000
Received: from [10.21.95.156] (sjc-vpn5-1948.cisco.com [10.21.95.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8QECQNt019622 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 26 Sep 2014 14:12:27 GMT
Message-ID: <54257449.2060703@cisco.com>
Date: Fri, 26 Sep 2014 07:12:25 -0700
From: Michael Barnes 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Acee Lindem 
References:  <54246A47.5060307@cisco.com>  <54250677.9020606@cisco.com>  <54251F08.7060502@linfre.de> 
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/1fuwRBLlSsWeEXNOZ5ksPQPpkN0
Cc: ospf@ietf.org
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
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, 26 Sep 2014 14:12:31 -0000

Hi Acee,

I obviously missed this part of the discussion for rfc5088. Thanks for 
drawing my attention to this.

Regards,
Michael

On 09/26/2014 04:49 AM, Acee Lindem wrote:
> Hi Michael, Manav, Karsten,
>
> We did have this discussion back when we put the first piece of
> non-OSPF information in the OSPF RI LSA and conceded that the OSPF RI
> LSA could be used for all types of information.
>
> https://datatracker.ietf.org/doc/rfc5088/
>
> On the same subject, I have further conceded that this will be used
> for variable length information and am doing a bis version of the
> RFC4970 accommodating multiple instance of the RI LSA. I will be
> presenting the updates in Honolulu.
>
> https://datatracker.ietf.org/doc/draft-acee-ospf-rfc4970bis/
>
> Thanks, Acee P.S. I’m glad I didn’t reply last night - we might have
> missed out on all the analogies ;^).
>
>
> On Sep 26, 2014, at 4:08 AM, Karsten Thomann
>  wrote:
>
>> Hi,
>>
>> RFC 4970 Section 3 includes:
>>
>> The purpose of the Router Information (RI) LSA is to advertise
>> information relating to the aggregate OSPF router.  Normally, this
>> should be confined to TLVs with a single value or very few values.
>> It is not meant to be a generic container to carry any and all
>> information.
>>
>> I think the first sentence allows it, as it is related to the ospf
>> router, even if it is not an ospf internal information. Michael is
>> right that not everything should be in the RI LSA as already
>> mentioned in the RFC, increasing the count of LSAs which need to
>> be flooded across the domain has also drawbacks in term of
>> scalability.
>>
>> Regards,
>>
>> Karsten
>>
>>
>> Am 26.09.2014 08:58, schrieb Manav Bhatia:
>>> Hi Michael,
>>>
>>> :-)
>>>
>>> Lets not deal with analogies (my bad!) lest we get misled by
>>> those.
>>>
>>> Clearly you and I look at RI LSAs differently. I dont think what
>>> youre suggesting is even remotely preposterous. However, i do
>>> believe that RIs can serve more than merely announcing OSPF
>>> specific router capabilities.
>>>
>>> And once again, we already have a precedent where RI was used
>>> for announcing non OSPF specific capability -- which means that
>>> the co-authors of this draft arent the only ones who think of RIs
>>> as being a generic tool for router capability advertisement.
>>>
>>> Lets hear what others have to say on this.
>>>
>>> Cheers, Manav
>>>
>>>
>>> On Fri, Sep 26, 2014 at 11:53 AM, Michael Barnes
>>>  wrote:
>>>> Hi Manav,
>>>>
>>>> That's a pretty funny analogy. I've got another one for you.
>>>>
>>>> Say the RI LSA is like a corporate learjet for a tool company.
>>>> When it gets flown around it's never full so you decide to use
>>>> it to ship wrenches on it along with the executives. You're
>>>> proud of your wrenches and want everyone to know how great they
>>>> are, but do you really want to ship them that way? Maybe it's
>>>> better to put the wrenches in their own vehicle.
>>>>
>>>> So to be a little more serious, if the router wants to proudly
>>>> proclaim its S-BFD capability then it deserves its own special
>>>> LSA rather than being packed into one used for other things.
>>>>
>>>> Cheers, Michael
>>>>
>>>>
>>>> On 09/25/2014 06:27 PM, Manav Bhatia wrote:
>>>>> Hi Michael,
>>>>>
>>>>> Very interesting.
>>>>>
>>>>> I think there is a disconnect because of our interpretation
>>>>> of what an RI LSA is envisioned to carry. I assume its meant
>>>>> to advertise "optional router capabilities" while you believe
>>>>> its to be used solely for advertising "optional OSPF router
>>>>> capabilities". IMO, limiting the scope of RI to just OSPF is
>>>>> like using a humvee with all its bells and whistles to
>>>>> distribute balloons to the children in your friendly
>>>>> neighborhood park! We wanted a mechanism wherein each router
>>>>> could proudly tell the world that it was an S-BFD capable
>>>>> node and along with it also advertise the unique
>>>>> discriminator that the others would use to reach it. RI we
>>>>> felt, was the perfect tool that we could use for this
>>>>> purpose.
>>>>>
>>>>> And btw we're not the first ones to use RI for advertising a
>>>>> router capability that isnt pertinent to OSPF per se (RFC
>>>>> 5088).
>>>>>
>>>>> Cheers, Manav
>>>>>
>>>>> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes
>>>>>  wrote:
>>>>>> Hi Manav,
>>>>>>
>>>>>> Perhaps I missed some earlier discussion, on why you
>>>>>> decided to add the S-BFD Discriminator TLV to the RI LSA,
>>>>>> but I would prefer it not be in that LSA. I would like to
>>>>>> leave the RI LSA with only information pertinent to OSPF
>>>>>> rather than pollute it with information for which OSPF has
>>>>>> no interest. If you're concerned with a trend of creating a
>>>>>> new Opaque type for every application which might want OSPF
>>>>>> to carry information for it, then I would suggest we create
>>>>>> a generic Application Information LSA.
>>>>>>
>>>>>> Regards, Michael
>>>>>>
>>>>>>
>>>>>> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We had submitted the following draft a couple of weeks
>>>>>>> ago.
>>>>>>>
>>>>>>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>>>>>>
>>>>>>>
>>>>>>>
This draft introduces a new OSPF RI TLV that allows OSPF routers to
>>>>>>> flood the S-BFD discriminator values in the routing
>>>>>>> domain.
>>>>>>>
>>>>>>> S-BFD is a new charter item (will be approved very soon)
>>>>>>> in the BFD WG.
>>>>>>>
>>>>>>> Would appreciate comments on this.
>>>>>>>
>>>>>>> Cheers, Manav
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ OSPF
>>>>>>> mailing list OSPF@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>>
>>>>> .
>>>>>
>>> _______________________________________________ OSPF mailing
>>> list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________ OSPF mailing list
>> OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
>
> .
>


From nobody Fri Sep 26 14:15: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 175321A6FDA; Fri, 26 Sep 2014 14:15:33 -0700 (PDT)
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 8hyaYVranv3W; Fri, 26 Sep 2014 14:15:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D01441A033B; Fri, 26 Sep 2014 14:15:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: akatlas@juniper.net, jdrake@juniper.net, sprevidi@cisco.com, dward@cisco.com, spencer.giacalone@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140926211531.21096.87157.idtracker@ietfa.amsl.com>
Date: Fri, 26 Sep 2014 14:15:31 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OBZVQ1C2LtHZBTxBPmL3845w_z8
Cc: ospf@ietf.org, ipr-announce@ietf.org
Subject: [OSPF] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-ospf-te-metric-extensions-06 and draft-ietf-isis-te-metric-extensions-03
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: Fri, 26 Sep 2014 21:15:33 -0000

Dear Alia Atlas, John Drake, Stefano Previdi, David Ward, Spencer Giacalone:

 An IPR disclosure that pertains to your Internet-Draft entitled "OSPF Traffic
Engineering (TE) Metric Extensions" (draft-ietf-ospf-te-metric-extensions) was
submitted to the IETF Secretariat on 2014-09-26 and has been posted on the "IETF
Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/2442/). The title of the IPR disclosure is
"Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ospf-
te-metric-extensions-06 and draft-ietf-isis-te-metric-extensions-03."");

The IETF Secretariat