From acee.lindem@ericsson.com Thu Oct 3 02:30:47 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992BE21F9D4C for ; Thu, 3 Oct 2013 02:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGz84dccLz29 for ; Thu, 3 Oct 2013 02:30:35 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6083221F9EE1 for ; Thu, 3 Oct 2013 02:30:00 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-01-524d39157f24 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 10.E7.03458.5193D425; Thu, 3 Oct 2013 11:29:58 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 05:29:57 -0400 From: Acee Lindem To: Rajib Majila Thread-Topic: Mail regarding draft-ietf-ospf-ospfv3-autoconfig Thread-Index: AQHOwASlI9PLx/zgAkW2E2LSvWff95ni+UKA Date: Thu, 3 Oct 2013 09:29:56 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030744EA@eusaamb101.ericsson.se> References: <524D1358.3020509@ericsson.com> In-Reply-To: <524D1358.3020509@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030744EAeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPuK6YpW+QwYWHvBYLNv9jt2i5d4/d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MrYuXc+a0GPZsWmbzeZGhg3KHUxcnJICJhI NB+ZwQxhi0lcuLeerYuRi0NI4CijRMOOyywQzjJGiQk/JrKDVLEJ6Eg8f/QPrEMEyG7ePJMV pIhZoI1R4u2502AJYQFbiY1LJ7JAFNlJXJ+9mAnCNpI4fH4b2CAWARWJxoWb2UBsXgFfiTNL OsF6hQS0JXZMmwpWwwm0YPKPvWBzGIHO+35qDdgcZgFxiVtP5jNBnC0gsWTPeagXRCVePv7H CmErSyx5sp8Foj5fYvmNbiaIXYISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjqF5riRVT76OoWcDIsYqRo7Q4tSw33chwEyMw4o5JsDnuYFzwyfIQozQHi5I475e3 zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGIN4OdbLvyh7vmFqg0/9+4e7WbXEFrI41Dg0 TvJp+/dmw0KrNb9/NT8omazgeZxJYNXqLscbHH8qPj/5cvVm14s7n/RZg4ryTfnK+YTYfz1l PxFj5HP2nFpkmsCpBRLR754r59ze0sa70EGX/c+amRPOH8ky2varIsg+6OSxS4YW8nYv3QOt JJRYijMSDbWYi4oTAQ+hHyGGAgAA Cc: OSPF List , "draft-ietf-ospf-ospfv3-autoconfig@tools.ietf.org" Subject: Re: [OSPF] Mail regarding draft-ietf-ospf-ospfv3-autoconfig X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 09:30:47 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030744EAeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding OSPF list. On Oct 3, 2013, at 2:48 AM, Rajib Majila wrote: Hi Acee/Arkko, I had a few questions/comments on your draft. Please find them below and cl= arify. 1. On using asynchronous hello/dead interval: Are you suggesting impleme= nting the LLS for supporting async hello/dead interval as mentioned in in your reference [ASYNC-HELLO]. No As I understand it may not be necessary as you are simply suggesting allowing a per neighbor hold time= r timer based on the hello/dead interval advertised by the neighbor in its hello packet. Yes 2. Router-id selection: It would probably be better to use a mechanism t= hat would most likely provide a unique id instead of a pseudo-random number. It can be a 32 bits hash of = the router-hardware- fingerprint as suggested in your draft. A regeneration of router-id can pos= sibly use a different hash function in case a collision was detected. Given that this fingerprint is u= sed even for detection of duplicates, I believe it can be expected to generate unique router-ids quit= e reliably. The pseudo-random number generation is seeded with an ID such as the router= -hardware-fingerprint. 3. Duplicate router-id detection: Can a self originated hello packet be = identified by looking at the source IPv6 address and comparing the same against the IP addresses of the local i= nterfaces. If you do not see any issue with this approach, it can eliminate the need to have a new LSA a= nd thereby simplifying the implementation. Hello are only exchanged between adjacent neighbors. The router-id must be= unique within the entire OSPF routing domain. Acee Rajib --_000_94A203EA12AECE4BA92D42DBFFE0AE47030744EAeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <1347671FF9480E48A5C3FDFCD2E270D7@ericsson.com> Content-Transfer-Encoding: quoted-printable Adding OSPF list.

On Oct 3, 2013, at 2:48 AM, Rajib Majila wrote:

Hi Acee/Arkko,

I had a few questions/comments on your draft. Please find them below and cl= arify.

1.    On using asynchronous hello/dead interval: Are you sug= gesting implementing the LLS for supporting
 async hello/dead interval as mentioned in in your reference [ASYNC-HE= LLO].

No 

As I understand it may not
be necessary as you are simply suggesting allowing a per neighbor hold time= r timer based on the
 hello/dead interval advertised by the neighbor in its hello packet.

Yes


2.    Router-id selection: It would probably be better to us= e a mechanism that would most likely provide
a unique id instead of a pseudo-random number. It can be a 32 bits hash of = the router-hardware-
fingerprint as suggested in your draft. A regeneration of router-id can pos= sibly use a different hash
function in case a collision was detected. Given that this fingerprint is u= sed even for detection of
duplicates, I believe it can be expected to generate unique router-ids quit= e reliably.

The pseudo-random number generation is seeded with an ID such as the r= outer-hardware-fingerprint. 



3.    Duplicate router-id detection: Can a self originated h= ello packet be identified by looking at the source
IPv6 address and comparing the same against the IP addresses of the local i= nterfaces. If you do not see
any issue with this approach, it can eliminate the need to have a new LSA a= nd thereby simplifying the
implementation.

Hello are only exchanged between adjacent neighbors.  The router-= id must be unique within the entire OSPF routing domain.  

Acee 


Rajib



--_000_94A203EA12AECE4BA92D42DBFFE0AE47030744EAeusaamb101erics_-- From acee.lindem@ericsson.com Thu Oct 3 05:37:31 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226FD11E80F2 for ; Thu, 3 Oct 2013 05:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPDlMaecoCXR for ; Thu, 3 Oct 2013 05:37:16 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B623E11E80E6 for ; Thu, 3 Oct 2013 05:35:40 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-3c-524d649a6fa1 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F6.5B.09414.A946D425; Thu, 3 Oct 2013 14:35:38 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 08:35:27 -0400 From: Acee Lindem To: Rajib Majila Thread-Topic: Mail regarding draft-ietf-ospf-ospfv3-autoconfig Thread-Index: AQHOwASlI9PLx/zgAkW2E2LSvWff95ni+UKAgAAUHYCAAB+4AA== Date: Thu, 3 Oct 2013 12:35:26 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030748E7@eusaamb101.ericsson.se> References: <524D1358.3020509@ericsson.com> <94A203EA12AECE4BA92D42DBFFE0AE47030744EA@eusaamb101.ericsson.se> <524D49F3.3030502@ericsson.com> In-Reply-To: <524D49F3.3030502@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPgu6sFN8gg21H5SwWbP7HbtFy7x67 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVxcvo2poLJAhUzVpxma2B8ytPFyMkhIWAi 0fnsPzuELSZx4d56ti5GLg4hgaOMEhO3vmWBcJYxSjy/t5kFpIpNQEfi+aN/zCC2CJDdvHkm K0gRs0Abo8Tbc6fBEsICthIbl05kgSiyk7g+ezFTFyMHkO0k8fuKAUiYRUBFYsvByWDlvAK+ Em9efGCCWDaRUWJe03mwXk6gBXuO7GMDsRmBzvt+ag0TiM0sIC5x68l8JoizBSSW7DnPDGGL Srx8/I8VwlaWWPJkPwtEvY7Egt2f2EBuYBawlug7LQMR1pZYtvA11A2CEidnPmGZwCg+C8mG WUi6ZyF0z0LSPQtJ9wJG1lWMHKXFqWW56UYGmxiBUXVMgk13B+Oel5aHGKU5WJTEeb+8dQ4S EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKhleOAua+3cozqearmXEzatDt2wPn5+S1TaJnE1 jyi3kPUzVQ79XbM2en7LxZgTxlY2iq5t899+LbR26y5kMlu2lTtGdcnVZ+5vpVW0DDinmXdc fX3g8Um5v1Zb9Gzsvq1t+LXD4i7v7e87Mrzf2sncjD28ZVZE8FMe44TTQr13J72cLn0i7pMS S3FGoqEWc1FxIgAiI0bVeAIAAA== Cc: OSPF List , "draft-ietf-ospf-ospfv3-autoconfig@tools.ietf.org" Subject: Re: [OSPF] Mail regarding draft-ietf-ospf-ospfv3-autoconfig X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 12:37:31 -0000 Hi Rajib, On Oct 3, 2013, at 6:41 AM, Rajib Majila wrote: > Hi Acee, >=20 > Thanks for the response. Please find my comments below on the last point. > " > 3. Duplicate router-id detection: Can a self originated hello packet b= e identified by looking at the source > IPv6 address and comparing the same against the IP addresses of the local= interfaces. If you do not see > any issue with this approach, it can eliminate the need to have a new LSA= and thereby simplifying the > implementation. >=20 > Hello are only exchanged between adjacent neighbors. The router-id must = be unique within the entire OSPF routing domain. > " >=20 > What I was getting at was not just hellos but any OSPFv3 packets which ca= n loosely be termed as link-scope. > Your primary intention here is to identify if the duplicate router-id det= ection mechanism is going to declare > an id as duplicate because multiple router interfaces are wrongly connect= ed to the same link. I was wondering > if this can be achieved simply by comparing the source IP address against= the link-local addresses of all the > local interfaces. Since here we are talking about link-local addresses, I= am not even considering the packets > which are non-link scope (area or AS). That would be the most straight forward way to implement duplicate detectio= n on a link. I did not describe implementation in the draft.=20 >=20 > Also your draft sets the flooding scope of this new LSA to Area-scope. If= you are actually trying to detect > duplicate router-id across the the OSPF domain by flooding this LSA acros= s the domain, should it not be set > to AS-scope? Also detecting a duplicate router-id across the domain might= be tricky as even AS-scope LSAs > are not forwarded into stub/nssa. I'd originally thought that area uniqueness would be good enough. I'm now t= hinking that it should be AS-External scope even though the initial auto-co= nfiguration use case is single area only.=20 Thanks, Acee >=20 > Rajib >=20 >=20 From chenxibj@cn.ibm.com Thu Oct 3 13:28:16 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC52B21E80D8 for ; Thu, 3 Oct 2013 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2vr57I7rYNZ for ; Thu, 3 Oct 2013 13:27:56 -0700 (PDT) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by ietfa.amsl.com (Postfix) with ESMTP id 771E821F9B07 for ; Thu, 3 Oct 2013 13:11:54 -0700 (PDT) Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Oct 2013 06:11:27 +1000 Received: from d23dlp02.au.ibm.com (202.81.31.213) by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 4 Oct 2013 06:11:25 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id 5E9732BB0040 for ; Fri, 4 Oct 2013 06:11:25 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r93JsMge9503024 for ; Fri, 4 Oct 2013 05:54:26 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r93KBLKZ000809 for ; Fri, 4 Oct 2013 06:11:21 +1000 Received: from d23ml021.cn.ibm.com (d23ml021.cn.ibm.com [9.119.32.97]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r93KBK71000794 for ; Fri, 4 Oct 2013 06:11:21 +1000 Auto-Submitted: auto-generated From: Xi R Chen To: ospf@ietf.org Message-ID: Date: Fri, 4 Oct 2013 04:08:52 +0800 X-MIMETrack: Serialize by Router on d23ml021/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 10/04/2013 04:08:53 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBF16ADFFD2A738f9e8a93df938690918cC7BBF16ADFFD2A73" Content-Disposition: inline X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13100320-6102-0000-0000-00000446C1D5 Subject: [OSPF] AUTO: Xi R Chen is out of the office (returning 10/07/2013) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 20:28:17 -0000 --0__=C7BBF16ADFFD2A738f9e8a93df938690918cC7BBF16ADFFD2A73 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 10/07/2013. I will be on CPS duty on 10.1 10.3 10.5 10.7 For anything urgent, you can reach me at +86 13810876541 Note: This is an automated response to your message "OSPF Digest, Vol = 92, Issue 1" sent on 10/04/2013 3:00:33. This is the only notification you will receive while this person is awa= y.= --0__=C7BBF16ADFFD2A738f9e8a93df938690918cC7BBF16ADFFD2A73 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 10= /07/2013.

I will be on CPS duty on &n= bsp;10.1 10.3 10.5 10.7
For anything urgent, you ca= n reach me at +86 13810876541


Note: Thi= s is an automated response to your message  "OSPF Digest, Vol 92, Issue 1" sent = on 10/04/2013 3:00:33.

This is t= he only notification you will receive while this person is away.= = --0__=C7BBF16ADFFD2A738f9e8a93df938690918cC7BBF16ADFFD2A73-- From curtis@ipv6.occnc.com Fri Oct 4 13:47:54 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3453A21F9D46; Fri, 4 Oct 2013 13:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4mXgiNCFq+G; Fri, 4 Oct 2013 13:47:50 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id D56C121F9C78; Fri, 4 Oct 2013 13:47:49 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r94KkPxP031900; Fri, 4 Oct 2013 16:46:25 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310042046.r94KkPxP031900@gateway1.orleans.occnc.com> To: IETF Secretariat From: Curtis Villamizar In-reply-to: Your message of "Tue, 17 Sep 2013 15:23:36 PDT." <20130917222336.6526.26287.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 16:46:25 -0400 Cc: ospf@ietf.org, akatlas@juniper.net, dward@cisco.com, ipr-announce@ietf.org Subject: Re: [OSPF] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-extensions-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 20:47:54 -0000 In message <20130917222336.6526.26287.idtracker@ietfa.amsl.com> IETF Secretariat writes: > > Dear Alia Atlas, John Drake, Spencer Giacalone, Stefano Previdi, David Ward: > > 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 2013-09-17 and has been posted on the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2199/). The title of the IPR disclosure is > "Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric- > extensions-04.""); > > The IETF Secretariat > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Since two of the authors are named on the patent, it is hard to understand how they could not have known about the IPR. Since the patent was applied for in 2004 and the first iteration of this draft was in 2011, and at least two co-authors of the draft knew about the patent by way of also being co-inventors of the patent, this appears to be a blatent late disclosure of IPR. Would the authors please explain how this was allowed to occur. Also, the patent seems (to me) to apply only to local-repair paths and not to primary paths. Would the inventors please confirm (or deny). I'm not sure how all the prior art on using multiple metrics, including additive constraints on "paths", could be construed as not applying to "local-repair paths". But then again, I'm not a lawyer and hope never to be one. The patent system at work again. Curtis From curtis@ipv6.occnc.com Fri Oct 4 14:18:47 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3A521F9E4D for ; Fri, 4 Oct 2013 14:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6gdqBT3PMuE for ; Fri, 4 Oct 2013 14:18:42 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id C7D5821F9C78 for ; Fri, 4 Oct 2013 14:18:41 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r94LHMGH032067; Fri, 4 Oct 2013 17:17:22 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310042117.r94LHMGH032067@gateway1.orleans.occnc.com> To: Anton Smirnov From: Curtis Villamizar In-reply-to: Your message of "Tue, 17 Sep 2013 15:39:44 +0200." <52385BA0.2030801@cisco.com> Date: Fri, 04 Oct 2013 17:17:22 -0400 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Question to the field people X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 21:18:47 -0000 In message <52385BA0.2030801@cisco.com> Anton Smirnov writes: > Hi all, > it should be pretty obvious where this question is coming from but ... > I would appreciate if people using OSPF in their networks answered > (privately, if you want) a simple question: > > ISIS allows link metric to be in the range of 1-2^24 and path cost > during SPF calculation 2^32. > OSPF uses costs of 2^16 and 2^24 respectively. > Was it ever considered as a limitation or serious factor affecting > choice of IGP to usein the network? > > Thanks, > > Anton Not that I know of. Most networks use metrics that are mostly in the single decimal digit integer range, occasionally larger to denote slower links in an outer tier that are not to be used to repair core connectivity, but getting nowhere near the limits. Its like IPv4 TTL being limited to 255, which could in theory be a problem, but in practice isn't. Curtis From acee.lindem@ericsson.com Fri Oct 4 16:29:38 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679B721F9D62 for ; Fri, 4 Oct 2013 16:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP-uc3pph9yj for ; Fri, 4 Oct 2013 16:29:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A576321F9DBA for ; Fri, 4 Oct 2013 16:29:29 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-ef-524f4f564de1 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8A.4C.09414.65F4F425; Sat, 5 Oct 2013 01:29:27 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 4 Oct 2013 19:29:26 -0400 From: Acee Lindem To: OSPF List Thread-Topic: IETF 88 OSPF WG Meeting in Vancouver Thread-Index: AQHOwVmQbySpAo30RkeQq0U1pWusRw== Date: Fri, 4 Oct 2013 23:29:25 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030773CA@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <15C4A53B7C386843A599E5D04EE1C88D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyuXRPoG64v3+QwY5JPBYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+KrZYwF1RUTb+5na2BM6WLk5JAQMJH4Nv0bG4QtJnHh3nog m4tDSOAoo8SMTb/ZIZxljBI/j3Yzg1SxCehIPH/0D8wWEZCVWLpkPyuILSygJ7Fx4S2ouLHE lO1boGw9iU+Nv8FsFgEViWevpjCB2LwCvhLXV7awg9iMQJu/n1oDFmcWEJe49WQ+E8RFAhJL 9pxnhrBFJV4+/scKYStLLHmynwWiXkdiwe5PbBC2tcTPln6oOdoSyxa+ZobYJShxcuYTlgmM IrOQrJiFpH0WkvZZSNpnIWlfwMi6ipGjtDi1LDfdyGATIzDsj0mw6e5g3PPS8hCjNAeLkjjv l7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYpZoe7N/8PmiX0suIxmtW8tpXT6lLn+Ke +yJUskTW+tubkhsZ2/4Jejh6nOlQuC2XtGRlL9OXggPfpU2XPGF4O0XgvyzPGZnXmjPydR0m Vm5iEvz+OtNn+abbagEPbvtde5i25iLP14nWVrc1ymsuyDcdYexXPCsYz1mydG+o2qOj7s02 h/lnKLEUZyQaajEXFScCAHQeXDxJAgAA Subject: [OSPF] IETF 88 OSPF WG Meeting in Vancouver X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 23:29:38 -0000 We have a preliminary slot on Thursday afternoon. Please send Abhay and mys= elf you agenda requests.=20 Thanks, Acee= From acee@lindem.com Mon Oct 7 13:24:54 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEF121F8445 for ; Mon, 7 Oct 2013 13:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsSY017nUEqZ for ; Mon, 7 Oct 2013 13:24:48 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1CA11E8135 for ; Mon, 7 Oct 2013 13:24:34 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=Rs5H3VaK c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=DLDx8OX49g8A:10 a=On94-Kqe0LohZuGPMrYA:9 a=CjuIK1q_8ugA:10 a=GPeY6O3snON3tnCa:21 a=vmBdLIlNGmLjM0MR:21 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:61861] helo=[192.168.1.106]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 72/DD-07811-18813525; Mon, 07 Oct 2013 20:24:33 +0000 From: Acee Lindem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Oct 2013 16:24:32 -0400 Message-Id: <39397A08-58F0-474D-AA3F-17390CB01FEF@lindem.com> To: OSPF List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [OSPF] One more RFC 6506BIS Clarification X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 20:24:54 -0000 One more thing I intend to add is explicit specification that the OSPFv3 = packet should be dropped if the Security Association isn't found or has = expired. The text is analogous to the original RFC 2328 Appendix D text. = This will be added to section 4.6.=20 *************** *** 976,981 **** --- 976,986 ---- and the IPv6 header length is less than the amount necessary to include an Authentication Trailer. =20 + Locate the receiving interface's OSPFv3 SA using the SA ID in the + received AT. If the SA is not found, or if the SA is not valid for + reception (i.e., current time < KeyStartAccept or current time >=3D + KeyStopAccept), the OSPFv3 packet is dropped. +=20 If the cryptographic sequence number in the AT is less than or = equal to the last sequence number in the last OSPFv3 packet of the same OSPFv3 type successfully received from the neighbor, the OSPFv3 =20 Although I would hope no one would complain about this since it was = always implied in section 3 (see excerpt below), please speak now if you = have any concerns.=20 o Security Association Identifier (SA ID) This is a 16-bit unsigned integer used to uniquely identify an OSPFv3 SA, as manually configured by the network operator. The receiver determines the active SA by looking at the SA ID field in the incoming protocol packet. From mdubrovs@cisco.com Mon Oct 7 15:19:59 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABEC21E81C9 for ; Mon, 7 Oct 2013 15:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khWp9nZoCzSE for ; Mon, 7 Oct 2013 15:19:54 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 458DD21E80C6 for ; Mon, 7 Oct 2013 15:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2542; q=dns/txt; s=iport; t=1381184394; x=1382393994; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ckaPthslpBlSncpkRAy82WZrhT2WyzuYw1nEnXwj3bU=; b=F8ZFFIpKyWMvqF1eIh0SF7Qf3CmHuqJkYn91CgOWY9J7vVzSlHv/pARt sfwqcbnHed3ZFlcD7ZuvmJ5eLrGSI0bj0SJcrcMl2kqEnYVuZLg23rFbk /w+/FGmRtFEPrMZaxD+lH3vCYSsBsStEKwZHbQKvWHa/SQ0zDC7LY/ucM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFACAzU1KtJXG8/2dsb2JhbABPCoMHOFLBIYEeFnSCJQEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIh34MuyMEjg6BEjgGgxmBBAOqAYMkgio X-IronPort-AV: E=Sophos;i="4.90,1051,1371081600"; d="scan'208";a="268996007" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 07 Oct 2013 22:19:52 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r97MJqhw007215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 22:19:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 7 Oct 2013 17:19:52 -0500 From: "Mike Dubrovskiy (mdubrovs)" To: Acee Lindem , OSPF List Thread-Topic: [OSPF] One more RFC 6506BIS Clarification Thread-Index: AQHOw5tOpNjTElP0hUGWLqmcD1Z07pnpwzzw Date: Mon, 7 Oct 2013 22:19:51 +0000 Message-ID: <534FD0D7D9E99740A077CE1A38EB79C30328E0A3@xmb-aln-x03.cisco.com> References: <39397A08-58F0-474D-AA3F-17390CB01FEF@lindem.com> In-Reply-To: <39397A08-58F0-474D-AA3F-17390CB01FEF@lindem.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] One more RFC 6506BIS Clarification X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 22:19:59 -0000 Hi Acee, I like the change but we currently have the following text in rfc6506 "In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition and not advisable to disrupt routing. Therefore, the router SHOULD send a "last Authentication Key expiration" notification to the network operator and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by the network operator, or a new key is configured." The above text is difficult to apply to Accept keys. It should be either de= leted or modified. Thank you, Mike > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > Sent: Monday, October 07, 2013 1:25 PM > To: OSPF List > Subject: [OSPF] One more RFC 6506BIS Clarification >=20 > One more thing I intend to add is explicit specification that the OSPFv3 = packet > should be dropped if the Security Association isn't found or has expired.= The > text is analogous to the original RFC 2328 Appendix D text. This will be = added > to section 4.6. >=20 > *************** > *** 976,981 **** > --- 976,986 ---- > and the IPv6 header length is less than the amount necessary to > include an Authentication Trailer. >=20 > + Locate the receiving interface's OSPFv3 SA using the SA ID in the > + received AT. If the SA is not found, or if the SA is not valid for > + reception (i.e., current time < KeyStartAccept or current time >=3D > + KeyStopAccept), the OSPFv3 packet is dropped. > + > If the cryptographic sequence number in the AT is less than or equal > to the last sequence number in the last OSPFv3 packet of the same > OSPFv3 type successfully received from the neighbor, the OSPFv3 >=20 > Although I would hope no one would complain about this since it was alway= s > implied in section 3 (see excerpt below), please speak now if you have an= y > concerns. >=20 > o Security Association Identifier (SA ID) >=20 > This is a 16-bit unsigned integer used to uniquely identify an > OSPFv3 SA, as manually configured by the network operator. >=20 > The receiver determines the active SA by looking at the SA ID > field in the incoming protocol packet. >=20 >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee@lindem.com Mon Oct 7 15:36:20 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AED721E81F9 for ; Mon, 7 Oct 2013 15:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu5Pc+kSrl7H for ; Mon, 7 Oct 2013 15:36:15 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 5914D21E8220 for ; Mon, 7 Oct 2013 15:36:00 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=ZbSfx7pA c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=79--BDQ0ng8A:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=YsqAwtZ_ajkA:10 a=48vgC7mUAAAA:8 a=g3fbcE6pwPFSQxjLjwkA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=fVDDzfnymiW3ILQ8:21 a=JxGXqTriXfGO6sP3:21 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:64321] helo=[192.168.1.106]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 68/82-02700-05733525; Mon, 07 Oct 2013 22:36:00 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <534FD0D7D9E99740A077CE1A38EB79C30328E0A3@xmb-aln-x03.cisco.com> Date: Mon, 7 Oct 2013 18:35:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39397A08-58F0-474D-AA3F-17390CB01FEF@lindem.com> <534FD0D7D9E99740A077CE1A38EB79C30328E0A3@xmb-aln-x03.cisco.com> To: "Mike Dubrovskiy (mdubrovs)" X-Mailer: Apple Mail (2.1085) Cc: OSPF List Subject: Re: [OSPF] One more RFC 6506BIS Clarification X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 22:36:20 -0000 Hi Mike, I agree and don't see why this one configuration error should be handled = explicitly when there are many other possible errors. Actually, I'd = looked at this text before and meant to address it since I'd never = implement this. I'll discuss with the other authors.=20 Thanks, Acee=20 On Oct 7, 2013, at 6:19 PM, Mike Dubrovskiy (mdubrovs) wrote: > Hi Acee, >=20 > I like the change but we currently have the following text in rfc6506 >=20 > "In the event that the last key associated > with an interface expires, it is unacceptable to revert to an > unauthenticated condition and not advisable to disrupt routing. > Therefore, the router SHOULD send a "last Authentication Key > expiration" notification to the network operator and treat the key = as > having an infinite lifetime until the lifetime is extended, the key > is deleted by the network operator, or a new key is configured." >=20 > The above text is difficult to apply to Accept keys. It should be = either deleted > or modified. >=20 > Thank you, > Mike >=20 >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of >> Acee Lindem >> Sent: Monday, October 07, 2013 1:25 PM >> To: OSPF List >> Subject: [OSPF] One more RFC 6506BIS Clarification >>=20 >> One more thing I intend to add is explicit specification that the = OSPFv3 packet >> should be dropped if the Security Association isn't found or has = expired. The >> text is analogous to the original RFC 2328 Appendix D text. This will = be added >> to section 4.6. >>=20 >> *************** >> *** 976,981 **** >> --- 976,986 ---- >> and the IPv6 header length is less than the amount necessary to >> include an Authentication Trailer. >>=20 >> + Locate the receiving interface's OSPFv3 SA using the SA ID in = the >> + received AT. If the SA is not found, or if the SA is not valid = for >> + reception (i.e., current time < KeyStartAccept or current time = >=3D >> + KeyStopAccept), the OSPFv3 packet is dropped. >> + >> If the cryptographic sequence number in the AT is less than or = equal >> to the last sequence number in the last OSPFv3 packet of the same >> OSPFv3 type successfully received from the neighbor, the OSPFv3 >>=20 >> Although I would hope no one would complain about this since it was = always >> implied in section 3 (see excerpt below), please speak now if you = have any >> concerns. >>=20 >> o Security Association Identifier (SA ID) >>=20 >> This is a 16-bit unsigned integer used to uniquely identify an >> OSPFv3 SA, as manually configured by the network operator. >>=20 >> The receiver determines the active SA by looking at the SA ID >> field in the incoming protocol packet. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf From asmirnov@cisco.com Tue Oct 8 04:46:49 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6A311E81AC for ; Tue, 8 Oct 2013 04:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc044MirdcJP for ; Tue, 8 Oct 2013 04:46:44 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id EAC5321E819C for ; Tue, 8 Oct 2013 04:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4150; q=dns/txt; s=iport; t=1381232802; x=1382442402; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=o6eFWVI+x5qSmAp2bmJliA0bOyR9Ymutej3Wrnn9Nu0=; b=R87nV/DeewZonQ18HB2AAsltlGB6ptUiE9aBCya50cLR7MqloCRUe8pG xmd4IpZSyiMehdTrVwD8S5Ansadd6z8KH4s8uVhTrkAeSkWgtJQ5oxvvZ ljFVXOscN/juIUpqvcnuuP4+7GZWwYEHtvemZsMc6Q5Iz5B+a9Yuo+F7n s=; X-IronPort-AV: E=Sophos;i="4.90,1056,1371081600"; d="scan'208";a="18611368" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 08 Oct 2013 11:46:39 +0000 Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r98BkWdT030715; Tue, 8 Oct 2013 11:46:34 GMT Message-ID: <5253F098.6070101@cisco.com> Date: Tue, 08 Oct 2013 13:46:32 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Acee Lindem References: <39397A08-58F0-474D-AA3F-17390CB01FEF@lindem.com> <534FD0D7D9E99740A077CE1A38EB79C30328E0A3@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: Re: [OSPF] One more RFC 6506BIS Clarification X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 11:46:49 -0000 Hi Acee, RFC 6506 inherited this property from RFC 5709 which has this text word for word: > In the event that the last key associated > with an interface expires, it is unacceptable to revert to an > unauthenticated condition, and not advisable to disrupt routing. > Therefore, the router should send a "last Authentication Key > expiration" notification to the network manager and treat the key as > having an infinite lifetime until the lifetime is extended, the key > is deleted by network management, or a new key is configured. To me this property looks wrong from security point of view and in general I would agree to have it removed. OTOH difference between v2 and v3 specs is highly undesirable, so if RFC 6506 is changed so that this property is dropped (or made optional) then at the same time we should evaluate how the same change can be pushed into RFC 5709. Anton On 10/08/2013 12:35 AM, Acee Lindem wrote: > Hi Mike, > I agree and don't see why this one configuration error should be handled explicitly when there are many other possible errors. Actually, I'd looked at this text before and meant to address it since I'd never implement this. I'll discuss with the other authors. > Thanks, > Acee > > On Oct 7, 2013, at 6:19 PM, Mike Dubrovskiy (mdubrovs) wrote: > >> Hi Acee, >> >> I like the change but we currently have the following text in rfc6506 >> >> "In the event that the last key associated >> with an interface expires, it is unacceptable to revert to an >> unauthenticated condition and not advisable to disrupt routing. >> Therefore, the router SHOULD send a "last Authentication Key >> expiration" notification to the network operator and treat the key as >> having an infinite lifetime until the lifetime is extended, the key >> is deleted by the network operator, or a new key is configured." >> >> The above text is difficult to apply to Accept keys. It should be either deleted >> or modified. >> >> Thank you, >> Mike >> >>> -----Original Message----- >>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of >>> Acee Lindem >>> Sent: Monday, October 07, 2013 1:25 PM >>> To: OSPF List >>> Subject: [OSPF] One more RFC 6506BIS Clarification >>> >>> One more thing I intend to add is explicit specification that the OSPFv3 packet >>> should be dropped if the Security Association isn't found or has expired. The >>> text is analogous to the original RFC 2328 Appendix D text. This will be added >>> to section 4.6. >>> >>> *************** >>> *** 976,981 **** >>> --- 976,986 ---- >>> and the IPv6 header length is less than the amount necessary to >>> include an Authentication Trailer. >>> >>> + Locate the receiving interface's OSPFv3 SA using the SA ID in the >>> + received AT. If the SA is not found, or if the SA is not valid for >>> + reception (i.e., current time < KeyStartAccept or current time >= >>> + KeyStopAccept), the OSPFv3 packet is dropped. >>> + >>> If the cryptographic sequence number in the AT is less than or equal >>> to the last sequence number in the last OSPFv3 packet of the same >>> OSPFv3 type successfully received from the neighbor, the OSPFv3 >>> >>> Although I would hope no one would complain about this since it was always >>> implied in section 3 (see excerpt below), please speak now if you have any >>> concerns. >>> >>> o Security Association Identifier (SA ID) >>> >>> This is a 16-bit unsigned integer used to uniquely identify an >>> OSPFv3 SA, as manually configured by the network operator. >>> >>> The receiver determines the active SA by looking at the SA ID >>> field in the incoming protocol packet. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 acee.lindem@ericsson.com Tue Oct 8 06:00:51 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5901C11E81B7 for ; Tue, 8 Oct 2013 06:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9mGNE3Yu3Wx for ; Tue, 8 Oct 2013 06:00:43 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 91FCB11E81A0 for ; Tue, 8 Oct 2013 06:00:38 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-3f-525401efd55d Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 60.67.09414.FE104525; Tue, 8 Oct 2013 15:00:31 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 8 Oct 2013 09:00:31 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] One more RFC 6506BIS Clarification Thread-Index: AQHOxBwI+qIhIuwnX0iuwjrsMgHf1pnrB48A Date: Tue, 8 Oct 2013 13:00:30 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470307E749@eusaamb101.ericsson.se> References: <39397A08-58F0-474D-AA3F-17390CB01FEF@lindem.com> <534FD0D7D9E99740A077CE1A38EB79C30328E0A3@xmb-aln-x03.cisco.com> <5253F098.6070101@cisco.com> In-Reply-To: <5253F098.6070101@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <74CB25CC733C1241A5710BA16049B478@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPoO57xpAggyfbLS2m3ZrOZtGyjdWi 5d49dgdmjym/N7J6LFnyk8njw6ILrAHMUVw2Kak5mWWpRfp2CVwZVzv/sRTMV6343RbewLhd touRk0NCwETiYdN2dghbTOLCvfVsXYxcHEICRxklFv9YxgrhLGOUeP1pLxtIFZuAjsTzR/+Y QWwRATWJzXc/sYLYzAI2EjM/9oHFhQXMJE5/amWDqDGXWLL2MVS9kUTz/V1gNouAisT+K9dZ QGxeAV+Jows+QC27zChxpesSE0iCU0BT4uO0rWALGIHO+35qDRPEMnGJW0/mM0GcLSCxZM95 ZghbVOLl43+sELayxJIn+1kg6nUkFuz+xAZhW0v8m9cEdbS2xLKFr5khjhCUODnzCcsERvFZ SFbMQtI+C0n7LCTts5C0L2BkXcXIUVqcWpabbmSwiREYacck2HR3MO55aXmIUZqDRUmc98tb 5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKsU7G9tiNe0Ut7JG+r6j/WjrlTNeZnwtRG8 FaqfKhfcuzH1yTyFtoxNWwSCHlxmbP7fGxytb8V53Fak3EMr6lKw+3b+wu0mPuXPs2dHzjDN +Fr+6blT6vOiMEamH43m3EUSfQYt68pmLSgMKtaeEb77fQK7nof0O835087Hf84P9p7NLvBC iaU4I9FQi7moOBEAMdOJYoICAAA= Cc: OSPF List Subject: Re: [OSPF] One more RFC 6506BIS Clarification X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 13:00:51 -0000 Hi Anton, We are updating the security in OSPFv2 as well with draft-ietf-ospf-securit= y-extension-manual-keying-05.txt. This a different mechanism but it is wher= e we ultimately want to get.=20 Thanks, Acee=20 On Oct 8, 2013, at 7:46 AM, Anton Smirnov wrote: > Hi Acee, > RFC 6506 inherited this property from RFC 5709 which has this text word= for word: >=20 >> In the event that the last key associated >> with an interface expires, it is unacceptable to revert to an >> unauthenticated condition, and not advisable to disrupt routing. >> Therefore, the router should send a "last Authentication Key >> expiration" notification to the network manager and treat the key as >> having an infinite lifetime until the lifetime is extended, the key >> is deleted by network management, or a new key is configured. >=20 > To me this property looks wrong from security point of view and in genera= l I would agree to have it removed. OTOH difference between v2 and v3 specs= is highly undesirable, so if RFC 6506 is changed so that this property is = dropped (or made optional) then at the same time we should evaluate how the= same change can be pushed into RFC 5709. >=20 > Anton >=20 >=20 >=20 >=20 >=20 >=20 > On 10/08/2013 12:35 AM, Acee Lindem wrote: >> Hi Mike, >> I agree and don't see why this one configuration error should be handled= explicitly when there are many other possible errors. Actually, I'd looked= at this text before and meant to address it since I'd never implement this= . I'll discuss with the other authors. >> Thanks, >> Acee >>=20 >> On Oct 7, 2013, at 6:19 PM, Mike Dubrovskiy (mdubrovs) wrote: >>=20 >>> Hi Acee, >>>=20 >>> I like the change but we currently have the following text in rfc6506 >>>=20 >>> "In the event that the last key associated >>> with an interface expires, it is unacceptable to revert to an >>> unauthenticated condition and not advisable to disrupt routing. >>> Therefore, the router SHOULD send a "last Authentication Key >>> expiration" notification to the network operator and treat the key as >>> having an infinite lifetime until the lifetime is extended, the key >>> is deleted by the network operator, or a new key is configured." >>>=20 >>> The above text is difficult to apply to Accept keys. It should be eithe= r deleted >>> or modified. >>>=20 >>> Thank you, >>> Mike >>>=20 >>>> -----Original Message----- >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf O= f >>>> Acee Lindem >>>> Sent: Monday, October 07, 2013 1:25 PM >>>> To: OSPF List >>>> Subject: [OSPF] One more RFC 6506BIS Clarification >>>>=20 >>>> One more thing I intend to add is explicit specification that the OSPF= v3 packet >>>> should be dropped if the Security Association isn't found or has expir= ed. The >>>> text is analogous to the original RFC 2328 Appendix D text. This will = be added >>>> to section 4.6. >>>>=20 >>>> *************** >>>> *** 976,981 **** >>>> --- 976,986 ---- >>>> and the IPv6 header length is less than the amount necessary to >>>> include an Authentication Trailer. >>>>=20 >>>> + Locate the receiving interface's OSPFv3 SA using the SA ID in the >>>> + received AT. If the SA is not found, or if the SA is not valid f= or >>>> + reception (i.e., current time < KeyStartAccept or current time >= =3D >>>> + KeyStopAccept), the OSPFv3 packet is dropped. >>>> + >>>> If the cryptographic sequence number in the AT is less than or equ= al >>>> to the last sequence number in the last OSPFv3 packet of the same >>>> OSPFv3 type successfully received from the neighbor, the OSPFv3 >>>>=20 >>>> Although I would hope no one would complain about this since it was al= ways >>>> implied in section 3 (see excerpt below), please speak now if you have= any >>>> concerns. >>>>=20 >>>> o Security Association Identifier (SA ID) >>>>=20 >>>> This is a 16-bit unsigned integer used to uniquely identify an >>>> OSPFv3 SA, as manually configured by the network operator. >>>>=20 >>>> The receiver determines the active SA by looking at the SA ID >>>> field in the incoming protocol packet. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee@lindem.com Tue Oct 8 07:41:48 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192C11E80E2 for ; Tue, 8 Oct 2013 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxTsgd4GbL7O for ; Tue, 8 Oct 2013 07:41:43 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2662F21E80A7 for ; Tue, 8 Oct 2013 07:41:42 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=ZbSfx7pA c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=RmXT5ZoxVT0A:10 a=Wma4Of2gTTwA:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=Ot9CBkG7GQsA:10 a=48vgC7mUAAAA:8 a=OtRtnS6h4b9WP6yVFWcA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=ZkulUW3Hn7q6ca7L:21 a=ZceCB0YnhfXsdcxf:21 a=cucfpPSLfxQysmeTMh4A:9 a=_W_S_7VecoQA:10 a=xF5BQeCZJuAiiNgN:21 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:56783] helo=[192.168.1.106]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 71/3E-02700-5A914525; Tue, 08 Oct 2013 14:41:42 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-14--790824029 From: Acee Lindem In-Reply-To: <523857D5.7050903@cisco.com> Date: Tue, 8 Oct 2013 10:41:41 -0400 Message-Id: <4A9113E9-9C65-418B-9F2F-ADFCFB4BEE00@lindem.com> References: <523857D5.7050903@cisco.com> To: Anton Smirnov X-Mailer: Apple Mail (2.1085) Cc: "ospf@ietf.org" Subject: Re: [OSPF] Notes on draft-acee-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 14:41:48 -0000 --Apple-Mail-14--790824029 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Anton,=20 Thanks for the review.=20 On Sep 17, 2013, at 9:23 AM, Anton Smirnov wrote: > Hi, > a few notes on current revision of ELSA draft (starting from = editorial going to more important). >=20 > Cosmetic notes: >=20 >> 6. OSPFv3 E-Inter-Area-Prefix-LSA >> ... >> All LSA Header fields are the same as defined for the Network-LSA. >=20 > Should be IAP LSA. Yup. Good catch.=20 >=20 >=20 >> Lindem, et al. Expires March 14, 2014 [Page = 20] >> =0C >> Internet-Draft OSPFv3 LSA Extendibility September = 2013 >>=20 >>=20 >> families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address = TLV >> is only applicable to the E-Link-LSA. Inclusion in other Extended >> LSAs MUST be ignored. Only a single instance of the IPv6 = Link-Local >> Address family SHOULD be included in the E-Link-LSA. Instances >> preceding the first MUST be ignored. >=20 > It is probably meant to be "instances following the first ..." Yes.=20 >=20 >=20 >=20 > Page 21: >> Address family SHOULD be included in the E-Link-LSA. Instances >> preceding the first MUST be ignored. For IPv6 address families as >> defined in [OSPFV3-AF].=20 > Incomplete sentence. Thanks - I've fixed this sentence to indicate that the TLV will be = ignored for OSPFv3 IPv6 address families.=20 >=20 >=20 >> For simplicity and to avoid the scaling impact of maintaining both >> TLV and non-TLV based versions of the same LSA within a routing >> domain, the basic backward compatibility mode will not allow = mixing >> of LSA formats. Different formats could still be supported with >> multiple OSPFv3 instances and separate OSPFv3 routing domains. > "Basic compatibility mode" is confusing name for a mode when instance = enabled with new functionality will not even talk to instance not = enabled for (or not supporting) it. There are many ways to provide compatibility. One is to not allow = incompatible neighbor to form adjacencies.=20 >=20 >=20 >=20 > Notes to functionality: >=20 > Tag field in E-ASE-LSAs is made optional. > Subject of propagating tags together with Intra- and Inter- area = routes was raised more than once. It is very likely that sooner or later = tag sub-TLVs will be proposed for Intra- and Inter- Area E-LSA. In this = case implementations will have to deal with optional tag field in E-ASE = LSA and tag sub-TLV in Intra-/Inter- Prefix TLV. This is inconvenient. = It is better to avoid optional field in E-ASE-LSA and define tag sub-TLV = for External-Prefix TLV from the beginning. I agree that this would clean up the encoding. However, if an = implementation already supports the AS-External-LSA, they need to = support the optional tag and forwarding address anyway. With respect to = future tags, I see the E-AS-External LSA as always having more affinity = with the AS-External-LSA than other LSAs where tags would be specified.=20= >=20 >=20 >=20 >> In order to retain compatibility and semantics with the current >> OSPFv3 specification, each LSA MUST contain a single Inter-Area >> Prefix TLV. This will facilitate migration and avoid changes to >> functions such as incremental SPF computation. > I appreciate ease of migration. OTOH, for better or worse but = E-Intra-Area-Prefix LSA can propagate multiple prefixes in single LSA. = So well-developed implementation will have to be able to work with an = LSA advertising multiple prefixes. It is a pity to restrict once and = forever Inter- and Ex- Prefix TLVs if Intra- does not have such = limitation. > To give implementations possibility of future optimizations = (advertising multiple prefixes in single LSA) and still keep advantage = of faster standardization and deployment I propose: > - Allow Inter- and Ex- TLVs to be present more than once in respective = LSAs > - Stipulate that routers running in any Migration mode MUST advertise = TLV only once per LSA. We can discuss further in an E-mail thread just on this subject. The = goal of this draft is to get OSPFv3 to flexible LSA format as quickly as = possible. Hence, changes are kept to what is necessary. Since you are an = implementer, you can appreciate that this is much more than an encoding = change as it changes the underlying semantics of the LSAs impacting = areas including incremental route computation, summary route origination = in ABRs, and NSSA translation. As for migration, we certainly don't want = more than one level of encoding. However, I think we are open to = discussions.=20 Thanks, Acee=20 >=20 > Thanks, >=20 > Anton >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-14--790824029 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Anton, 


Thanks for the = review. 

On Sep 17, 2013, at 9:23 AM, Anton = Smirnov wrote:

=20 =20
   Hi,
   a few notes on current revision of = ELSA draft  (starting from editorial going to more = important).

Cosmetic notes:

6.  OSPFv3 E-Inter-Area-Prefix-LSA
...
   All LSA Header fields are the same as defined for the =
Network-LSA.

Should be IAP LSA.

Yup. = Good catch. 




Lindem, et al.           Expires March 14, 2014               =
 [Page 20]
=0C
Internet-Draft          OSPFv3 LSA Extendibility          September 2013


   families as defined in [OSPFV3-AF].  The IPv6 Link-Local Address TLV
   is only applicable to the E-Link-LSA.  Inclusion in other Extended
   LSAs MUST be ignored.  Only a single instance of the IPv6 Link-Local
   Address family SHOULD be included in the E-Link-LSA.  Instances
   preceding the first MUST be ignored.

It is probably meant to be "instances following the first = ..."

Yes. 





Page 21:
   Address family SHOULD be included in the E-Link-LSA.  =
Instances
   preceding the first MUST be ignored.  For IPv6 address families as
   defined in [OSPFV3-AF].
Incomplete sentence.

Thanks - I've = fixed this sentence to indicate that the TLV will be ignored for OSPFv3 = IPv6 address families. 



   For simplicity and to avoid the scaling impact of =
maintaining both
   TLV and non-TLV based versions of the same LSA within a routing
   domain, the basic backward compatibility mode will not allow mixing
   of LSA formats. Different formats could still be supported with
   multiple OSPFv3 instances and separate OSPFv3 routing domains.
"Basic compatibility mode" is confusing name for a mode when instance enabled with new functionality will not even talk to instance not enabled for (or not supporting) = it.

There are many ways to = provide compatibility. One is to not allow incompatible neighbor to form = adjacencies. 




Notes to functionality:

Tag field in E-ASE-LSAs is made optional.
Subject of propagating tags together with Intra- and Inter- area routes was raised more than once. It is very likely that sooner or later tag sub-TLVs will be proposed for Intra- and Inter- Area E-LSA. In this case implementations will have to deal with optional tag field in E-ASE LSA and tag sub-TLV in Intra-/Inter- Prefix TLV. This is inconvenient. It is better to avoid optional field in E-ASE-LSA and define tag sub-TLV for External-Prefix TLV from the beginning.

I agree that = this would clean up the encoding. However, if an implementation already = supports the AS-External-LSA, they need to support the optional tag and = forwarding address anyway. With respect to future tags, I see the = E-AS-External LSA as always having more affinity with the = AS-External-LSA than other LSAs where tags would be = specified. 

 

   In order to retain compatibility and semantics with the =
current
   OSPFv3 specification, each LSA MUST contain a single Inter-Area
   Prefix TLV.  This will facilitate migration and avoid changes to
   functions such as incremental SPF computation.
I appreciate ease of migration. OTOH, for better or worse but E-Intra-Area-Prefix LSA can propagate multiple prefixes in single LSA. So well-developed implementation will have to be able to work with an LSA advertising multiple prefixes. It is a pity to restrict once and forever Inter- and Ex- Prefix TLVs if Intra- does not have such limitation.
   To give implementations possibility of future = optimizations (advertising multiple prefixes in single LSA) and still keep advantage of faster standardization and deployment I propose:
- Allow Inter- and Ex- TLVs to be present more than once in respective LSAs
- Stipulate that routers running in any Migration mode MUST advertise TLV only once per = LSA.

We can discuss further in = an E-mail thread just on this subject. The goal of this draft is to get = OSPFv3 to flexible LSA format as quickly as possible. Hence, changes are = kept to what is necessary. Since you are an implementer, you can = appreciate that this is much more than an encoding change as it changes = the underlying semantics of the LSAs impacting areas including = incremental route computation, summary route origination in ABRs, and = NSSA translation. As for migration, we certainly don't want more than =  one level of encoding. However, I think we are open to = discussions. 

Thanks,
Acee 





<= /div>





=


Thanks,

Anton



_______________________________________________
OSPF mailing = list
OSPF@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ospf

= --Apple-Mail-14--790824029-- From wwwrun@rfc-editor.org Wed Oct 9 03:37:08 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AB411E8163 for ; Wed, 9 Oct 2013 03:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoZeljyMo2tZ for ; Wed, 9 Oct 2013 03:37:07 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id F223211E8178 for ; Wed, 9 Oct 2013 03:37:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ED8ADB1E011; Wed, 9 Oct 2013 03:29:18 -0700 (PDT) To: jmoy@casc.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20131009102918.ED8ADB1E011@rfc-editor.org> Date: Wed, 9 Oct 2013 03:29:18 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC2328 (3746) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 10:37:08 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3746 -------------------------------------- Type: Technical Reported by: Ramakrishna DTV Section: GLOBAL Original Text ------------- *. Section 3.3. (Classification of routers) says: AS boundary routers A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router advertises AS external routing information throughout the Autonomous System. The paths to each AS boundary router are known by every router in the AS. This classification is completely independent of the previous classifications: AS boundary routers may be internal or area border routers, and may or may not participate in the backbone. *. Section 10.6 (Receiving Database Description Packets) says: When the router accepts a received Database Description Packet as the next in sequence the packet contents are processed as follows. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS- external-LSA (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. *. Section 13. (The Flooding Procedure) says: (3) Else if this is an AS-external-LSA (LS type = 5), and the area has been configured as a stub area, discard the LSA and get the next one from the Link State Update Packet. AS-external-LSAs are not flooded into/throughout stub areas (see Section 3.6). (4) Else if the LSA's LS age is equal to MaxAge, and there is currently no instance of the LSA in the router's link state database, and none of router's neighbors are in states Exchange Corrected Text -------------- *. Section 3.3. (Classification of routers) should say: AS boundary routers A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router advertises AS external routing information throughout the Autonomous System. The paths to each AS boundary router are known by every router in the AS (except stub areas). This classification is completely independent of the previous classifications: AS boundary routers may be internal or area border routers, and may or may not participate in the backbone. *. Section 10.6 (Receiving Database Description Packets) should say: When the router accepts a received Database Description Packet as the next in sequence the packet contents are processed as follows. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS- external-LSA (LS type = 5) and the neighbor is associated with a stub area, or if this is a type-4 summary LSA and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. *. Section 13. (The Flooding Procedure) should say: There should be an additional step in between steps 3 and 4 in Section 13. The additional step below is denoted 3.5: (3) Else if this is an AS-external-LSA (LS type = 5), and the area has been configured as a stub area, discard the LSA and get the next one from the Link State Update Packet. AS-external-LSAs are not flooded into/throughout stub areas (see Section 3.6). (3.5) Else if this is a type-4 Summary LSA (LS type = 4), and the area has been configured as a stub area, discard the LSA and get the next one from the Link State Update Packet. Type-4 Summary LSAs are not flooded into/throughout stub areas. (4) Else if the LSA's LS age is equal to MaxAge, and there is currently no instance of the LSA in the router's link state database, and none of router's neighbors are in states Exchange Notes ----- This whole note is regarding stub areas. RFC 2328 is already consistent with respect to AS-external-LSAs (LS type =5). The RFC explicitly indicates that they should be neither sent nor received in stub areas. But RFC 2328 seems to have some omissions with respect to type-4 Summary LSA (LS type = 4). The RFC explicitly indicates that these LSAs should never be sent in stub areas. But it does not mention what should be done if these LSAs are received in stub areas. The above updates try to remedy this omission. If the neighbor is associated with a stub area, then we should never receive a type-4 summary LSA from that neighbor. Here are the relevant quotes from the RFC: Section 12.4.3.1.(Originating summary-LSAs into stub areas): "As specified in Section 12.4.3, Type 4 summary-LSAs (ASBR-summary-LSAs) are never originated into stub areas." Section 4.2. (AS external routes): "To utilize external routing information, the path to all routers advertising external information must be known throughout the AS (excepting the stub areas). For that reason, the locations of these AS boundary routers are summarized by the (non-stub) area border routers." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee.lindem@ericsson.com Wed Oct 9 10:42:10 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1221E805F for ; Wed, 9 Oct 2013 10:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WpX1JlssNlT for ; Wed, 9 Oct 2013 10:42:06 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBAE21E8149 for ; Wed, 9 Oct 2013 10:42:02 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-df-52559568eda9 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5B.08.03458.86595525; Wed, 9 Oct 2013 19:42:01 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 13:42:00 -0400 From: Acee Lindem To: RFC Errata System Thread-Topic: [Technical Errata Reported] RFC2328 (3746) Thread-Index: AQHOxNuAEuhjc6UFUUmCIpO6ZadDW5ns5wsA Date: Wed, 9 Oct 2013 17:41:59 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703080F0F@eusaamb101.ericsson.se> References: <20131009102918.ED8ADB1E011@rfc-editor.org> In-Reply-To: <20131009102918.ED8ADB1E011@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZXLonVjdzamiQwZqTIhY/em4wWxw+OIvN ouXePXaL2QduMlk07f/KZnHu6RxGBzaPKb83snosWfKTyWPBpDZ2jxWbVzJ6NLQdYw1gjeKy SUnNySxLLdK3S+DK+H1qAlvBf/OKi412DYw7NLsYOTkkBEwkdh1+ywZhi0lcuLceyObiEBI4 yigxp3MlO0hCSGAZo8TL+9ogNpuAjsTzR/+YQWwRAUOJg4vesoM0MAtsZZRYNPc/E0hCWMBc Ysq6QywQRRYSu393sUPYRhLTev8zgtgsAioS5xvvg9XwCvhKzDx9iAlimbnEj0k7WLsYOTg4 gXon380HCTMCHff91BqwEmYBcYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtrLEkif7WSDqdSQW 7P7EBjKSWcBaYvMOR4iwtsSyha+ZIS4QlDg58wnLBEbxWUg2zELSPQuhexaS7llIuhcwsq5i 5CgtTi3LTTcy3MQIjMpjEmyOOxgXfLI8xCjNwaIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsZo351N+90Xf/2/7vWLvhMrds/++8jet/pv/B51ozy2qcbXlngoGE+S1vBdk5F+ p/fqtVtZTzstZ3D6R3MFBK+ys2Zk+fYsS9W/fEay7tNLXnvOXpkTxJKcYzn7sWaYppU5b5ZH rl/Ok0i2v0acr7l/qikxzO5/e1wpZxvr1/ecBxS1hRf/81NiKc5INNRiLipOBABp77h5mAIA AA== Cc: OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3746) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 17:42:11 -0000 I already responded to Ramakrishna on the OSPF list that he is correct and = this is an omission from RFC 2328.=20 http://www.ietf.org/mail-archive/web/ospf/current/msg06720.html This errata should be accepted.=20 Thanks, Acee On Oct 9, 2013, at 6:29 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3746 >=20 > -------------------------------------- > Type: Technical > Reported by: Ramakrishna DTV >=20 > Section: GLOBAL >=20 > Original Text > ------------- > *. Section 3.3. (Classification of routers) says: >=20 > AS boundary routers > A router that exchanges routing information with routers > belonging to other Autonomous Systems. Such a router > advertises AS external routing information throughout the > Autonomous System. The paths to each AS boundary router are > known by every router in the AS. This classification is > completely independent of the previous classifications: AS > boundary routers may be internal or area border routers, and > may or may not participate in the backbone. >=20 > *. Section 10.6 (Receiving Database Description Packets) says: >=20 > When the router accepts a received Database Description Packet > as the next in sequence the packet contents are processed as > follows. For each LSA listed, the LSA's LS type is checked for > validity. If the LS type is unknown (e.g., not one of the LS > types 1-5 defined by this specification), or if this is an AS- > external-LSA (LS type =3D 5) and the neighbor is associated with a > stub area, generate the neighbor event SeqNumberMismatch and > stop processing the packet. >=20 > *. Section 13. (The Flooding Procedure) says: >=20 > (3) Else if this is an AS-external-LSA (LS type =3D 5), and the area > has been configured as a stub area, discard the LSA and get the > next one from the Link State Update Packet. AS-external-LSAs > are not flooded into/throughout stub areas (see Section 3.6). >=20 > (4) Else if the LSA's LS age is equal to MaxAge, and there is > currently no instance of the LSA in the router's link state > database, and none of router's neighbors are in states Exchange >=20 >=20 > Corrected Text > -------------- > *. Section 3.3. (Classification of routers) should say: >=20 > AS boundary routers > A router that exchanges routing information with routers > belonging to other Autonomous Systems. Such a router > advertises AS external routing information throughout the > Autonomous System. The paths to each AS boundary router are > known by every router in the AS (except stub areas). This > classification is > completely independent of the previous classifications: AS > boundary routers may be internal or area border routers, and > may or may not participate in the backbone. >=20 > *. Section 10.6 (Receiving Database Description Packets) should say: >=20 > When the router accepts a received Database Description Packet > as the next in sequence the packet contents are processed as > follows. For each LSA listed, the LSA's LS type is checked for > validity. If the LS type is unknown (e.g., not one of the LS > types 1-5 defined by this specification), or if this is an AS- > external-LSA (LS type =3D 5) and the neighbor is associated with a > stub area, or if this is a type-4 summary LSA and the neighbor > is associated with a stub area, generate the neighbor event > SeqNumberMismatch and stop processing the packet. >=20 > *. Section 13. (The Flooding Procedure) should say: >=20 > There should be an additional step in between steps 3 and 4 in > Section 13. The additional step below is denoted 3.5: >=20 > (3) Else if this is an AS-external-LSA (LS type =3D 5), and the area > has been configured as a stub area, discard the LSA and get the > next one from the Link State Update Packet. AS-external-LSAs > are not flooded into/throughout stub areas (see Section 3.6). >=20 > (3.5) Else if this is a type-4 Summary LSA (LS type =3D 4), and the > area has been configured as a stub area, discard the LSA and get > the next one from the Link State Update Packet. Type-4 Summary > LSAs are not flooded into/throughout stub areas. >=20 > (4) Else if the LSA's LS age is equal to MaxAge, and there is > currently no instance of the LSA in the router's link state > database, and none of router's neighbors are in states Exchange >=20 >=20 > Notes > ----- > This whole note is regarding stub areas. >=20 > RFC 2328 is already consistent with respect to AS-external-LSAs > (LS type =3D5). The RFC explicitly indicates that they should be neither > sent nor received in stub areas. >=20 > But RFC 2328 seems to have some omissions with respect to type-4 > Summary LSA (LS type =3D 4). The RFC explicitly indicates that these > LSAs should never be sent in stub areas. But it does not mention what > should be done if these LSAs are received in stub areas. >=20 > The above updates try to remedy this omission. >=20 > If the neighbor is associated with a stub area, then we should never > receive a type-4 summary LSA from that neighbor. Here are the relevant > quotes from the RFC: >=20 > Section 12.4.3.1.(Originating summary-LSAs into stub areas): >=20 > "As specified in Section 12.4.3, Type 4 summary-LSAs > (ASBR-summary-LSAs) are never originated into stub > areas." >=20 > Section 4.2. (AS external routes): >=20 > "To utilize external routing information, the path to all routers > advertising external information must be known throughout the AS > (excepting the stub areas). For that reason, the locations of > these AS boundary routers are summarized by the (non-stub) area > border routers." >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : INTERNET STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG From acee.lindem@ericsson.com Thu Oct 10 14:24:32 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDFB21E8094; Thu, 10 Oct 2013 14:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wINRhRUTizbx; Thu, 10 Oct 2013 14:24:26 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id AAB0D21E80B0; Thu, 10 Oct 2013 14:24:15 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-d9-52571afc966b Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.65.09414.CFA17525; Thu, 10 Oct 2013 23:24:12 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 10 Oct 2013 17:24:11 -0400 From: Acee Lindem To: "" Thread-Topic: [OSPF] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-extensions-04 Thread-Index: AQHOwUMCfZ0niXWrMU28dusXfzup9ZnuvqYA Date: Thu, 10 Oct 2013 21:24:10 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030834C3@eusaamb101.ericsson.se> References: <201310042046.r94KkPxP031900@gateway1.orleans.occnc.com> In-Reply-To: <201310042046.r94KkPxP031900@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <8A3A207997C02947A84EB7376CAF2242@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonQfePVHiQwdu7EhZfr6VZTJ51hs3i wIZvjBbt2+6zWJztnsFu0XLvHrsDm8eU3xtZPZYs+cnksez+RTaP601X2QNYorhsUlJzMstS i/TtErgymuf7FrwRrfjV9YylgfGZYBcjJ4eEgInEt5MX2SFsMYkL99azdTFycQgJHGWUOHnp DBOEs5xR4sGTaWwgVWwCOhLPH/1jBrFFBEwljm1pBitiFrjBKNHzYCYLSEJYoFDixd2zjBBF RRLHF+0EinMA2UYSL1ZFgIRZBFQlvr2/yApi8wr4Spx6d4ERpERIwEVi1wIVkDCngKvE562T wFYxAh33/dQaJhCbWUBc4taT+UwQRwtILNlznhnCFpV4+fgfK4StLLHkyX4WiHodiQW7P7FB 2NYSm1v3MUPY2hLLFr5mhjhBUOLkzCcsExjFZyFZMQtJ+ywk7bOQtM9C0r6AkXUVI0dpcWpZ brqRwSZGYDQek2DT3cG456XlIUZpDhYlcd4vb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTDaK/97EaLFqV301SBZxmTy1HTWQmOWG5aCO67ttrl47KLF6+glofnKzjPV1Q0nWMxsebHs Q5Wt36Lnk2LEQ6sWLV5/RPLE+u31eTFzvPyv3rOwzs+PvS3zvdNFyWL1VJE3Mm3WZe9fruys mF58fwf/CdVNT3bufGdd1F6enKjLmf4uhf/Yh0AlluKMREMt5qLiRADawkcrlAIAAA== Cc: "" , "" , IETF Secretariat , "" , "" Subject: Re: [OSPF] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-extensions-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 21:24:32 -0000 Hi Curtis,=20 The draft was first presented at IETF 80 in Prague in the Routing, ISIS, an= d OSPF WGs. At the time, the biggest concern was the overlap with other del= ay/loss encoding drafts in the CCAMP WG. I looked at the minutes of the 3 W= Gs and IPR was not declared or questioned. I also spoke to one of the paten= t authors and the timing of the IPR declaration was not intentional - both = the draft/patent authors are co-authors on a fair number of Internet drafts= and patents. In the future, we'll assure the IPR question is raised prior = to making any draft an OSPF WG document.=20 I won't comment as to whether the simple encoding and advertisement of thes= e delay/loss metrics actually violates a patent specifying specific usage o= f the metrics.=20 Thanks, Acee=20 On Oct 4, 2013, at 4:46 PM, Curtis Villamizar wrote: >=20 > In message <20130917222336.6526.26287.idtracker@ietfa.amsl.com> > IETF Secretariat writes: >=20 >>=20 >> Dear Alia Atlas, John Drake, Spencer Giacalone, Stefano Previdi, David W= ard: >>=20 >> An IPR disclosure that pertains to your Internet-Draft entitled "OSPF Tr= affic >> Engineering (TE) Metric Extensions" (draft-ietf-ospf-te-metric-extension= s) was >> submitted to the IETF Secretariat on 2013-09-17 and has been posted on t= he "IETF >> Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/2199/). The title of the IPR disclosur= e is >> "Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric- >> extensions-04.""); >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >=20 >=20 > Since two of the authors are named on the patent, it is hard to > understand how they could not have known about the IPR. >=20 > Since the patent was applied for in 2004 and the first iteration of > this draft was in 2011, and at least two co-authors of the draft knew > about the patent by way of also being co-inventors of the patent, this > appears to be a blatent late disclosure of IPR. >=20 > Would the authors please explain how this was allowed to occur. >=20 > Also, the patent seems (to me) to apply only to local-repair paths and > not to primary paths. Would the inventors please confirm (or deny). >=20 > I'm not sure how all the prior art on using multiple metrics, > including additive constraints on "paths", could be construed as not > applying to "local-repair paths". But then again, I'm not a lawyer > and hope never to be one. The patent system at work again. >=20 > Curtis > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From curtis@ipv6.occnc.com Fri Oct 11 09:12:26 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4859911E821F; Fri, 11 Oct 2013 09:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5npvvP41zdo4; Fri, 11 Oct 2013 09:12:26 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9321F9E94; Fri, 11 Oct 2013 09:12:25 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r9BG9ipn031101; Fri, 11 Oct 2013 12:09:44 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310111609.r9BG9ipn031101@gateway1.orleans.occnc.com> To: Acee Lindem From: Curtis Villamizar In-reply-to: Your message of "Thu, 10 Oct 2013 21:24:10 -0000." <94A203EA12AECE4BA92D42DBFFE0AE47030834C3@eusaamb101.ericsson.se> Date: Fri, 11 Oct 2013 12:09:44 -0400 Cc: "" , "" , IETF Secretariat , "" , "" Subject: Re: [OSPF] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-extensions-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:12:26 -0000 Acee, Thanks for the reply on this and providing the history from WG chair perspective. Thanks also for considering explicitly asking for IPR statements from the authors when accepting a WG doc. It would also be helpful to ask for IPR statements before each WGLC the way the MPLS WG does. btw- It would appear to me that advertising the parameters is not the issue, but rather using them for delay bounded path computation for the protection LSP is the reason the IPR would apply. I think that mention of use in delay bounded path computation was added late in the game and may account for the late IPR. Curtis In message <94A203EA12AECE4BA92D42DBFFE0AE47030834C3@eusaamb101.ericsson.se> Acee Lindem writes: > > Hi Curtis, > > The draft was first presented at IETF 80 in Prague in the Routing, > ISIS, and OSPF WGs. At the time, the biggest concern was the overlap > with other delay/loss encoding drafts in the CCAMP WG. I looked at the > minutes of the 3 WGs and IPR was not declared or questioned. I also > spoke to one of the patent authors and the timing of the IPR > declaration was not intentional - both the draft/patent authors are > co-authors on a fair number of Internet drafts and patents. In the > future, we'll assure the IPR question is raised prior to making any > draft an OSPF WG document. > > I won't comment as to whether the simple encoding and advertisement of > these delay/loss metrics actually violates a patent specifying > specific usage of the metrics. > > Thanks, > Acee > > On Oct 4, 2013, at 4:46 PM, Curtis Villamizar wrote: > > > > > In message <20130917222336.6526.26287.idtracker@ietfa.amsl.com> > > IETF Secretariat writes: > > > >> > >> Dear Alia Atlas, John Drake, Spencer Giacalone, Stefano Previdi, David Ward: > >> > >> 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 2013-09-17 and has been posted on the "IETF > >> Page of Intellectual Property Rights Disclosures" > >> (https://datatracker.ietf.org/ipr/2199/). The title of the IPR disclosure is > >> "Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric- > >> extensions-04.""); > >> > >> The IETF Secretariat > >> > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www.ietf.org/mailman/listinfo/ospf > > > > > > Since two of the authors are named on the patent, it is hard to > > understand how they could not have known about the IPR. > > > > Since the patent was applied for in 2004 and the first iteration of > > this draft was in 2011, and at least two co-authors of the draft knew > > about the patent by way of also being co-inventors of the patent, this > > appears to be a blatent late disclosure of IPR. > > > > Would the authors please explain how this was allowed to occur. > > > > Also, the patent seems (to me) to apply only to local-repair paths and > > not to primary paths. Would the inventors please confirm (or deny). > > > > I'm not sure how all the prior art on using multiple metrics, > > including additive constraints on "paths", could be construed as not > > applying to "local-repair paths". But then again, I'm not a lawyer > > and hope never to be one. The patent system at work again. > > > > Curtis > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Sat Oct 12 14:25:05 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C5921E81A5 for ; Sat, 12 Oct 2013 14:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-0lRrntC4oM for ; Sat, 12 Oct 2013 14:24:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 49DB821E80AC for ; Sat, 12 Oct 2013 14:24:59 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-48-5259be252160 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 64.DE.03458.52EB9525; Sat, 12 Oct 2013 23:24:53 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Sat, 12 Oct 2013 17:24:49 -0400 From: Acee Lindem To: Acee Lindem , OSPF List Thread-Topic: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" Thread-Index: AQHOx5F629fImVztJUO21xkHOUAZ6g== Date: Sat, 12 Oct 2013 21:24:48 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703086BC3@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyuXSPn67qvsggg9ZJlhYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48D7u2wFywQrmn/MZW5gnMvXxcjJISFgIrF84noWCFtM4sK9 9WwgtpDAUUaJnZ1hXYxcQPZyRonPXfcYQRJsAjoSzx/9YwaxRQRcJd4+XQfWICzgLXH30DtG iLiPxPe9L9khbD2Jm4s2sILYLAKqEqt/fQXr5RXwlfh5/xwTiM0p4Cfxa/1pMJsR6Ijvp9aA 2cwC4hK3nsxngjhOQGLJnvPMELaoxMvH/8BmigLN7561nBUirizxfc4jFoheHYkFuz+xQdjW EksvbYGytSWWLXwNdYOgxMmZT1gmMIrNQrJuFpL2WUjaZyFpn4WkfQEj6ypGjtLi1LLcdCPD TYzASDkmwea4g3HBJ8tDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPT8 EsAS/3bRlocr7zbrn/i3etFyb5nQvKizi4rizWXuqe/bYrpe2EE1KfTs5HVsIao+r+1kRXZI 7KrT+9igolx03/5H7wftltTfAgdXuHJe4Kv5t8zEYG2KmqXQpMlaT3j2ld1zz3CyObnoqru0 p42+zgGuWq9l4qX6BSE/LX3cGP4U+5zqUWIpzkg01GIuKk4EAJemVhZiAgAA Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2013 21:25:05 -0000 We've gotten plenty of support for this becoming a WG document. I plan to post it next week incorporating some comments. Thanks, Acee On 9/16/13 5:24 AM, "Acee Lindem" wrote: >This version includes changes in support of backward compatibility. >Speaking as both a WG chair and author, this document is essential to >OSPFv3 protocol extension. Please indicate your support or objections by >September 30th, 2013. >Thanks, >Acee=20 > >On Sep 10, 2013, at 5:54 PM, > wrote: > >>=20 >> A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt >> has been successfully submitted by Acee Lindem and posted to the >> IETF repository. >>=20 >> Filename: draft-acee-ospfv3-lsa-extend >> Revision: 02 >> Title: OSPFv3 LSA Extendibility >> Creation date: 2013-09-10 >> Group: Individual Submission >> Number of pages: 29 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-acee-ospfv3-lsa-extend-02.txt >> Status: =20 >>http://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend >> Htmlized: =20 >>http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend-02 >> Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospfv3-lsa-extend-02 >>=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 LSA. This document extends >> the LSA format by allowing the optional inclusion of Type-Length- >> Value (TLV) tuples in the LSAs. Backward compatibility mechanisms >> are also described. >>=20 >>=20 >>=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. >>=20 >> The IETF Secretariat >>=20 > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Sat Oct 12 14:34:07 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F12421F9C69 for ; Sat, 12 Oct 2013 14:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiRXSAymymsQ for ; Sat, 12 Oct 2013 14:34:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB2521F9BCE for ; Sat, 12 Oct 2013 14:34:01 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-77-5259c049095c Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CD.DE.03458.940C9525; Sat, 12 Oct 2013 23:34:01 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Sat, 12 Oct 2013 17:33:00 -0400 From: Acee Lindem To: Acee Lindem , OSPF List Thread-Topic: [OSPF] Poll for WG Adoption of draft-baker-ipv6-ospf-dst-src-routing-03.txt Thread-Index: AQHOstiPFvKkLdrSeEmnp51nfAa89pnxjUYA Date: Sat, 12 Oct 2013 21:32:59 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703086BF5@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052AD7@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPn67ngcggg8YNMhbTDjxgsmi5d4/d 4lPXc1aLc0/nMDqweEz5vZHVY8mSn0weJ+bOY/K4P20iUwBLFJdNSmpOZllqkb5dAlfGxksn mAtmsVV8/zyZtYFxHmsXIyeHhICJxM3ph6BsMYkL99azdTFycQgJHGWUePLiAiuEs5xR4tGv JywgVWwCOhLPH/1jBrFFBFwl3j5dxwZiMwuUSLTebASLCwtESVx8uhGqJlri7debULaRxLkP /9hBbBYBVYkXUw8xgti8Ar4Sy892AdkcHJwCfhK3VuaAhBmBDvp+ag0TxHhxiVtP5jNBHCog sWTPeWYIW1Ti5eN/YA+ICuhJdM9aDvWMssT3OY9YIHp1JBbs/gR1prXEha7z7BC2tsSyha+Z IU4QlDg58wnLBEbxWUjWzULSPgtJ+ywk7bOQtC9gZF3FyFFanFqWm25kuIkRGH3HJNgcdzAu +GR5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYx9M+w7D1jWNB/gmM6k yFmmqnbrv+Tq7U4ZFqJS3RzvlrJZb+WY8t+rXYEn4vXjsM/RByXTNxrfvn2s5YdzW67b5u/b 9/hEFpdJ/pwofzd6tU/i4ug13K6qa5R7HpqzmmYXfJwb/e6Po3/MRNf9fXvD97BEG6jxG1/4 cfrrz2UXoh9f2XhAKkeJpTgj0VCLuag4EQBakeNpjAIAAA== Cc: Ray Bellis , Mark Townsley Subject: Re: [OSPF] Poll for WG Adoption of draft-baker-ipv6-ospf-dst-src-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2013 21:34:07 -0000 This document hasn't received a lot of discussion on this list. However, speaking as Routing Area advisor to the Homenet WG, I'd like to see it accepted as a WG document given that this is a requirement for multi-homed home networks.=20 Thanks, Acee On 9/16/13 5:30 AM, "Acee Lindem" wrote: >This document includes the encodings necessary for source/destination >routing. The source/destination routing is required by the Homenet WG in >support of flexible multi-homed IPv6 deployment. It uses the flexible >OSPFv3 encodings. Please indicate your support or objections by September >30th, 2013.=20 >Thanks, >Acee=20 >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Thu Oct 17 07:39:27 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2979111E810F for ; Thu, 17 Oct 2013 07:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=-1.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVoQHHzzLqJV for ; Thu, 17 Oct 2013 07:39:21 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5556C11E80F5 for ; Thu, 17 Oct 2013 07:39:13 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-af-525ff690c515 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F7.BC.03458.096FF525; Thu, 17 Oct 2013 16:39:12 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Thu, 17 Oct 2013 10:39:12 -0400 From: Acee Lindem To: OSPF List Thread-Topic: NOMCOM - Critical shortage of nominees for multiple areas Thread-Index: AQHOy0S8AhAZQg1pWEaJSKihhs73gw== Date: Thu, 17 Oct 2013 14:39:11 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470308EEF2@eusaamb101.ericsson.se> References: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470308EEF2eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXSPt+6Eb/FBBv8uW1i03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKWbdjEVvLCu+NJyhLGB8ZJxFyMnh4SAicTKNzMYIWwxiQv3 1rN1MXJxCAkcZZRYs3gNK4SznFGiZ/V8VpAqNgEdieeP/jGD2CICshJLl+wHiwsLuEt8ffMR Ku4u8ahlNhOErSfReXUzWJxFQFXi5IFmMJtXwFdi1od3YLaQgKPE3eNvwOYwAl3x/dQasF5m AXGJW0/mM0FcJyCxZM95ZghbVOLl43+sELayxJIn+1kg6vMlpsw4zwIxX1Di5MwnLBMYhWch GTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHgM1WstcffSLyZkNQsYOVYxcpQWp5blphsZ bmIExsoxCTbHHYwLPlkeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OC z3bfPTi05sdaiM7R3cf31cfT+VjPz+w7uWnThC2e6Sw88jOppr9NRe2a3i8m6fj8Y7zr5wVE 7X4Y1TntTL+XjduqPJ3Zmmviw7e+y4mvnd5wLbtIc90Zb/UlS9V5/r83T6nfdf/8dG7RK0EP du7cH13+dZNQQ8kCc9ufz268z+o72xBdz6HEUpyRaKjFXFScCABaCifIYwIAAA== Subject: [OSPF] Fwd: NOMCOM - Critical shortage of nominees for multiple areas X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 14:39:27 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470308EEF2eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Begin forwarded message: From: NomCom Chair 2013 > Date: October 17, 2013 10:24:34 AM EDT To: IETF Announcement List > Cc: IETF Discuss > Subject: NOMCOM - Critical shortage of nominees for multiple areas Reply-To: >, >, >, <"2013 [Catchier Subject line - apologies to those offended by a duplicate] A critically low number of people have accepted nominations for some of the IESG open positions. There is only one nominee per slot in APP, OPS and TS= V, only two in INT and RAI. Many folks have declined nominations. While the Nomcom appreciates that support for two years of intense service is hard to assure, and while we are aware that there is much support for th= e incumbents who are standing, the IETF should continually be considering which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation. Therefore, we urgently request that more nominees come forward. DEADLINES Nominations - October 18 Questionnaires from nominees - October 25 Not coincidentally, this is a good time to think over and send your comment= s about the current statements of desired expertise of positions - this is pa= rt of the Nomcom's annual review process as well. Send them to nomcom13@ietf.org= . Definitive location [*] of the current statements on desired expertise: https://datatracker.ietf.org/nomcom/2013/expertise/ Instructions and details on nomination [**]: https://datatracker.ietf.org/ann/nomcom/60602/ Thanks, everyone, Allison for the Nomcom [*] This year the Nomcom tools were recoded, and also transitioned into the datatracker. Apologies for a number of places where we didn't catch refere= nce errors. [**] Yes, alas, the previous call for nominations used "OAM" instead of "OP= S," but we have* corrected this (chair's pilot) error where it occurred in the Nomc= om pages. --_000_94A203EA12AECE4BA92D42DBFFE0AE470308EEF2eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <3510C906A73AE944BC322B18694EB409@ericsson.com> Content-Transfer-Encoding: quoted-printable

Begin forwarded message:

From: NomCo= m Chair 2013 <nomcom-chair= -2013@ietf.org>
Date: Octob= er 17, 2013 10:24:34 AM EDT
To: IETF = Announcement List <ietf-announ= ce@ietf.org>
Cc: IETF = Discuss <ietf@ietf.org>
Subject: NO= MCOM - Critical shortage of nominees for multiple areas
Reply-To: <<= a href=3D"mailto:ietf@ietf.org">ietf@ietf.org>, <Nomcom@ietfa.amsl.com>, <Chair@ietfa.amsl.com>, <"2013 <nomcom-chair-2013"@ietf.org>

[Catchier Subject line - apologies to those offended by a duplicate]
A critically low number of people have accepted nominations for some of the=
IESG open positions.  There is only one nominee per slot in APP, OPS a= nd TSV,
only two in INT and RAI.  Many folks have declined nominations.  =

While the Nomcom appreciates that support for two years of intense service =
is hard to assure, and while we are aware that there is much support for th= e
incumbents who are standing, the IETF should continually be considering
which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation.

Therefore, we urgently request that more nominees come forward.  

DEADLINES
Nominations - October 18
Questionnaires from nominees - October 25

Not coincidentally, this is a good time to think over and send your comment= s
about the current statements of desired expertise of positions - this is pa= rt of
the Nomcom's annual review process as well.  Send them to nomcom13@ietf.org.

Definitive location [*] of the current statements on desired expertise:
     https://datatracker.ietf.org/nomcom/2013/expertise/<= br>
Instructions and details on nomination [**]:
     https://datatracker.ietf.org/ann/nomcom/60602/

Thanks, everyone,

Allison for the Nomcom

[*] This year the Nomcom tools were recoded, and also transitioned into the=
datatracker.  Apologies for a number of places where we didn't catch r= eference
errors.

[**] Yes, alas, the previous call for nominations used "OAM" inst= ead of "OPS," but
we have* corrected this (chair's pilot) error where it occurred in the Nomc= om
pages.

--_000_94A203EA12AECE4BA92D42DBFFE0AE470308EEF2eusaamb101erics_-- From wwwrun@rfc-editor.org Fri Oct 18 17:43:34 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4421511E8100; Fri, 18 Oct 2013 17:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AaZuAIkOgjq; Fri, 18 Oct 2013 17:43:33 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B213111E8102; Fri, 18 Oct 2013 17:43:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0DBB58E018; Fri, 18 Oct 2013 17:35:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131019003506.0DBB58E018@rfc-editor.org> Date: Fri, 18 Oct 2013 17:35:06 -0700 (PDT) Cc: drafts-update-ref@iana.org, ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 7038 on Use of OSPF-MDR in Single-Hop Broadcast Networks X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2013 00:43:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7038 Title: Use of OSPF-MDR in Single-Hop Broadcast Networks Author: R. Ogier Status: Experimental Stream: IETF Date: October 2013 Mailbox: ogier@earthlink.net Pages: 7 Characters: 15535 Updates: RFC 5614 I-D Tag: draft-ietf-ospf-manet-single-hop-mdr-04.txt URL: http://www.rfc-editor.org/rfc/rfc7038.txt RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From shraddha@juniper.net Mon Oct 21 04:06:06 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B474611E818D for ; Mon, 21 Oct 2013 04:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fijTZKw6dLww for ; Mon, 21 Oct 2013 04:05:59 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id BA39C11E8390 for ; Mon, 21 Oct 2013 04:05:52 -0700 (PDT) Received: from mail115-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 11:05:32 +0000 Received: from mail115-tx2 (localhost [127.0.0.1]) by mail115-tx2-R.bigfish.com (Postfix) with ESMTP id 2331480072; Mon, 21 Oct 2013 11:05:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I936eI1454I542I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail115-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shraddha@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(53754006)(199002)(189002)(13464003)(52044002)(377454003)(377424004)(80022001)(66066001)(33646001)(49866001)(47976001)(47736001)(50986001)(65816001)(83072001)(56776001)(54316002)(76482001)(74662001)(31966008)(79102001)(74502001)(54356001)(80976001)(74316001)(53806001)(81816001)(81342001)(47446002)(69226001)(81542001)(19580395003)(83322001)(19580405001)(59766001)(63696002)(15202345003)(77982001)(76576001)(51856001)(46102001)(81686001)(74366001)(15975445006)(76786001)(77096001)(74706001)(85306002)(56816003)(74876001)(76796001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB127.namprd05.prod.outlook.com; CLIP:116.197.178.91; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail115-tx2 (localhost.localdomain [127.0.0.1]) by mail115-tx2 (MessageSwitch) id 1382353530290913_4517; Mon, 21 Oct 2013 11:05:30 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.241]) by mail115-tx2.bigfish.com (Postfix) with ESMTP id 42CE7E006F; Mon, 21 Oct 2013 11:05:30 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 11:05:30 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 21 Oct 2013 11:05:29 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 21 Oct 2013 11:05:26 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.230]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.230]) with mapi id 15.00.0785.001; Mon, 21 Oct 2013 11:05:26 +0000 From: Shraddha Hegde To: OSPF List Thread-Topic: Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzkvgNHObxoS1x0Of7JHPuwEEI5n+/UtA Date: Mon, 21 Oct 2013 11:05:25 +0000 Message-ID: <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> In-Reply-To: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.91] x-forefront-prvs: 00064751B6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Harish Raghuveer , Rob Shakir Subject: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 11:06:06 -0000 SGkgQWxsLA0KDQpXZSBoYXZlIHBvc3RlZCBhIGRyYWZ0IG9uICIgQWR2ZXJ0aXNpbmcgcGVyLW5v ZGUgYWRtaW5pc3RyYXRpdmUgdGFncyBpbiBPU1BGIiBhbmQgd291bGQgbGlrZSB0byBoZWFyIHlv dXIgdmlld3Mgb24gaXQuIFBsZWFzZSBmZWVsIGZyZWUgdG8gcmFpc2UgYW55IHN1Z2dlc3Rpb24v Y29tbWVudCBvbiB0aGUgY29udGVudC4NCg0KUmdkcw0KU2hyYWRkaGENCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjEsIDIwMTMg NDoyNCBQTQ0KVG86IEhhcmlzaCBSYWdodXZlZXI7IFNocmFkZGhhIEhlZ2RlOyBCcml0aXNoIFRl bGVjb207IEhhbm5lcyBHcmVkbGVyOyBSb2IgU2hha2lyDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWhlZ2RlLW9zcGYtbm9kZS1hZG1pbi10YWctMDAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhlZ2RlLW9zcGYtbm9kZS1hZG1pbi10YWct MDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNocmFkZGhhIEhlZ2Rl IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1o ZWdkZS1vc3BmLW5vZGUtYWRtaW4tdGFnDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBBZHZlcnRp c2luZyBwZXItbm9kZSBhZG1pbmlzdHJhdGl2ZSB0YWdzIGluIE9TUEYNCkNyZWF0aW9uIGRhdGU6 CSAyMDEzLTEwLTIxDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBw YWdlczogNg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1oZWdkZS1vc3BmLW5vZGUtYWRtaW4tdGFnLTAwLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhlZ2RlLW9zcGYtbm9k ZS1hZG1pbi10YWcNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaGVnZGUtb3NwZi1ub2RlLWFkbWluLXRhZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYW4gZXh0ZW5zaW9uIHRvIE9TUEYgcHJvdG9jb2wgW1JGQzIz MjhdIHRvDQogICBhZGQgYW4gb3B0aW9uYWwgb3BlcmF0aW9uYWwgY2FwYWJpbGl0eSwgdGhhdCBh bGxvd3MgdGFnZ2luZyBhbmQNCiAgIGdyb3VwaW5nIG9mIHRoZSBub2RlcyBpbiBhbiBPU1BGIGRv bWFpbi4gIFRoaXMgYWxsb3dzDQogICBzaW1wbGlmaWNhdGlvbixlYXNlIG9mIG1hbmFnZW1lbnQg YW5kIGNvbnRyb2wgb3ZlciByb3V0ZSBhbmQgcGF0aA0KICAgc2VsZWN0aW9uIGJhc2VkIG9uIGNv bmZpZ3VyZWQgcG9saWNpZXMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBwcm90 b2NvbCBleHRlbnNpb25zIHRvIGRpc3NlbWluYXRlIHBlci0NCiAgIG5vZGUgYWRtaW4tdGFncyB0 byB0aGUgT1NQRnYyIGFuZCBPU1BGdjMgcHJvdG9jb2xzLg0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0KDQo= From acee.lindem@ericsson.com Mon Oct 21 06:14:38 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B98511E8552 for ; Mon, 21 Oct 2013 06:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwmKMxg2dWKP for ; Mon, 21 Oct 2013 06:14:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id F190C11E84F9 for ; Mon, 21 Oct 2013 06:12:28 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-5b-5265283c9f87 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 75.E3.09414.C3825625; Mon, 21 Oct 2013 15:12:28 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 09:12:27 -0400 From: Acee Lindem To: Shraddha Hegde Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzkvgNHObxoS1x0Of7JHPuwEEI5n+/UtAgABniwA= Date: Mon, 21 Oct 2013 13:12:27 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> In-Reply-To: <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FF0F10BE2E84D4FA058B234F902A068@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXSPn66NRmqQwfqr0hbNlzazW7Tcu8du sefdWkaLG4/2MjuweLR9mczksWTJTyaP601X2QOYo7hsUlJzMstSi/TtErgyOmZ+YS+YKVTx sukzcwPjA74uRk4OCQETicMHZjBD2GISF+6tZ+ti5OIQEjjKKNHw+xMTSEJIYDmjRPsGUxCb TUBH4vmjf2ANIgKaEtcmPmUFsZkFciR+vzoAVM/BISyQKfH/uh+IKSKQJdG+1gSi2kri45wm dhCbRUBVovfDMzCbV8BX4uydg8wQa3sZJSasOc0IkuAUCJPoePmfDcRmBLrt+6k1TBCrxCVu PZnPBHGzgMSSPeeh7heVePn4HyuErSyx5Ml+Foh6HYkFuz+xQdjWEss3v2WHsLUlli18zQxx hKDEyZlPWCYwis9CsmIWkvZZSNpnIWmfhaR9ASPrKkaO0uLUstx0I4NNjMCIOybBpruDcc9L y0OM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgbDvx94qijIr6ZcHDc1Xb 72/o71/bscyyRux/Zcv9GxvSAj5Ib/3HMXNh59J1j8SXynxcJLc9Lvjn8vZZLBVWN6an+4dt 2rfvS/eRQ87VOd6/8zdx93mfsTdaLTFtO9/cjuzM91PmJ/k7iWXyF134qNh+gpfz3hGrjsBr ek/zH+c9Ti/z0y3br8RSnJFoqMVcVJwIAKXKbc+GAgAA Cc: OSPF List , Harish Raghuveer , Rob Shakir Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 13:14:38 -0000 Hi Shraddha,=20 Since the size of the tag data is unbounded, could you either put it in a s= eparate OSPFv2 opaque LSA and OSPFv3 LSA or limit the size to some maximum = number of tags, e.g., 16? =20 Thanks, Acee=20 On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: > Hi All, >=20 > We have posted a draft on " Advertising per-node administrative tags in O= SPF" and would like to hear your views on it. Please feel free to raise any= suggestion/comment on the content. >=20 > Rgds > Shraddha >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Monday, October 21, 2013 4:24 PM > To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hannes Gredler; Ro= b Shakir > Subject: New Version Notification for draft-hegde-ospf-node-admin-tag-00.= txt >=20 >=20 > A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt > has been successfully submitted by Shraddha Hegde and posted to the IETF = repository. >=20 > Filename: draft-hegde-ospf-node-admin-tag > Revision: 00 > Title: Advertising per-node administrative tags in OSPF > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-hegde-ospf-nod= e-admin-tag-00.txt > Status: http://datatracker.ietf.org/doc/draft-hegde-ospf-node-ad= min-tag > Htmlized: http://tools.ietf.org/html/draft-hegde-ospf-node-admin-t= ag-00 >=20 >=20 > Abstract: > This document describes an extension to OSPF protocol [RFC2328] to > add an optional operational capability, that allows tagging and > grouping of the nodes in an OSPF domain. This allows > simplification,ease of management and control over route and path > selection based on configured policies. >=20 > This document describes the protocol extensions to disseminate per- > node admin-tags to the OSPFv2 and OSPFv3 protocols. >=20 >=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 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From hannes@juniper.net Mon Oct 21 06:27:57 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E03511E81BD for ; Mon, 21 Oct 2013 06:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxcgTvHNwl-X for ; Mon, 21 Oct 2013 06:27:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3F211E8507 for ; Mon, 21 Oct 2013 06:26:20 -0700 (PDT) Received: from mail69-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 13:26:19 +0000 Received: from mail69-ch1 (localhost [127.0.0.1]) by mail69-ch1-R.bigfish.com (Postfix) with ESMTP id 5E0FEC00A2; Mon, 21 Oct 2013 13:26:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0511HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz98dI9371I936eI1454Ic430I542I1432I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3h1155h) Received-SPF: pass (mail69-ch1: domain of juniper.net designates 157.56.232.213 as permitted sender) client-ip=157.56.232.213; envelope-from=hannes@juniper.net; helo=BLUPRD0511HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1 (MessageSwitch) id 1382361977643915_21453; Mon, 21 Oct 2013 13:26:17 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail69-ch1.bigfish.com (Postfix) with ESMTP id 996C41E004A; Mon, 21 Oct 2013 13:26:17 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 13:26:15 +0000 Received: from [172.26.200.238] (193.110.54.36) by pod51010.outlook.com (10.255.135.165) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 21 Oct 2013 13:26:14 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> Date: Mon, 21 Oct 2013 15:26:10 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 13:27:57 -0000 acee, why should we give an upper boundary on things which - might be subject to change and - which have a historic track record of being underestimated. the 'per-link' admin-groups serve as a good example here: initially conceived as "you won't ever need more than 32" we have now arrived at a variable length (unbounded) extension. http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-00 for a humorous take to it, have a look at http://tools.ietf.org/html/rfc1925 rule (9) and (10) /hannes On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: > Hi Shraddha,=20 > Since the size of the tag data is unbounded, could you either put it = in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the size to some = maximum number of tags, e.g., 16? =20 > Thanks, > Acee=20 > On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >=20 >> Hi All, >>=20 >> We have posted a draft on " Advertising per-node administrative tags = in OSPF" and would like to hear your views on it. Please feel free to = raise any suggestion/comment on the content. >>=20 >> Rgds >> Shraddha >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Monday, October 21, 2013 4:24 PM >> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hannes = Gredler; Rob Shakir >> Subject: New Version Notification for = draft-hegde-ospf-node-admin-tag-00.txt >>=20 >>=20 >> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt >> has been successfully submitted by Shraddha Hegde and posted to the = IETF repository. >>=20 >> Filename: draft-hegde-ospf-node-admin-tag >> Revision: 00 >> Title: Advertising per-node administrative tags in = OSPF >> Creation date: 2013-10-21 >> Group: Individual Submission >> Number of pages: 6 >> URL: = http://www.ietf.org/internet-drafts/draft-hegde-ospf-node-admin-tag-00.txt= >> Status: = http://datatracker.ietf.org/doc/draft-hegde-ospf-node-admin-tag >> Htmlized: = http://tools.ietf.org/html/draft-hegde-ospf-node-admin-tag-00 >>=20 >>=20 >> Abstract: >> This document describes an extension to OSPF protocol [RFC2328] to >> add an optional operational capability, that allows tagging and >> grouping of the nodes in an OSPF domain. This allows >> simplification,ease of management and control over route and path >> selection based on configured policies. >>=20 >> This document describes the protocol extensions to disseminate per- >> node admin-tags to the OSPFv2 and OSPFv3 protocols. >>=20 >>=20 >>=20 >>=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. >>=20 >> The IETF Secretariat >>=20 >>=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 >=20 >=20 From acee.lindem@ericsson.com Mon Oct 21 06:33:30 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BEF11E81A7 for ; Mon, 21 Oct 2013 06:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvbArkhqGOfv for ; Mon, 21 Oct 2013 06:33:24 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3311E83D4 for ; Mon, 21 Oct 2013 06:33:00 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-79-52652d0bea35 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 32.B4.03458.B0D25625; Mon, 21 Oct 2013 15:33:00 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 09:32:54 -0400 From: Acee Lindem To: Hannes Gredler Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzkvgNHObxoS1x0Of7JHPuwEEI5n+/UtAgABniwCAAAPWAIAAAeCA Date: Mon, 21 Oct 2013 13:32:54 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> In-Reply-To: <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <78FBECD5F7009B408E669422453D4C0D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiC6PbmqQwYyJ3Bb9956wWTRf2sxu 0XLvHrvFnndrGS1uPNrL7MDq0fZlMpPHkiU/mTyuN11lD2CO4rJJSc3JLEst0rdL4Mo4uWIZ Y8Ef6YqG5y3MDYwfxLoYOTkkBEwkuqdMYoSwxSQu3FvP1sXIxSEkcJRRYvLbi4wQznJGiQe/ V7CAVLEJ6Eg8f/SPGcQWEVCXWDjpLjNIEbPAZEaJv30bgIo4OIQFMiX+X/cDMUUEsiTa15pA lLtJnDzzhwnEZhFQlVh8cBOYzSvgK9GxaSc7iC0k0MYkMfOTKIjNKWAvcXZnL9gqRqDjvp9a A1bPLCAucevJfCaIowUkluw5zwxhi0q8fPyPFcJWlljyZD8LRL2OxILdn9ggbGuJr4uuQc3R lli28DUzxA2CEidnPmGZwCg+C8mKWUjaZyFpn4WkfRaS9gWMrKsYOUqLU8ty040MNzECo++Y BJvjDsYFnywPMUpzsCiJ83556xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXFbf0pj/Nby yLsO3/n436V2Je2IOKBc+6K87oWu1YHie4knL2yZ/N9x7mO3tfkeay44fk0XzSjfcXFiMnOQ +IvY48c9325ktpPeMFdL/tLyLRIpOdMTtLeq3zXuVi5I+thZsufWp4LAV8x2JQvesv47XZEe 6a4+qenVwnP9bf/42I+oHGwvOqTEUpyRaKjFXFScCABCM1hXjAIAAA== Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 13:33:30 -0000 Hannes,=20 On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: > acee, >=20 > why should we give an upper boundary on things which > - might be subject to change and > - which have a historic track record of being underestimated. You don't have to - just request a separate OSPFv2 opaque LSA and IPv6 OSPF= v3 LSA from IANA. Another alternative would be to extend the RI LSA to be multi-instance and = relegate the variable length tags to an instance other than instance 0.=20 Acee=20 >=20 > the 'per-link' admin-groups serve as a good example here: > initially conceived as "you won't ever need more than 32" we have > now arrived at a variable length (unbounded) extension. >=20 > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-00 >=20 > for a humorous take to it, have a look at > http://tools.ietf.org/html/rfc1925 > rule (9) and (10) >=20 > /hannes >=20 > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: >=20 >> Hi Shraddha,=20 >> Since the size of the tag data is unbounded, could you either put it in = a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the size to some maxim= um number of tags, e.g., 16? =20 >> Thanks, >> Acee=20 >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >>=20 >>> Hi All, >>>=20 >>> We have posted a draft on " Advertising per-node administrative tags in= OSPF" and would like to hear your views on it. Please feel free to raise a= ny suggestion/comment on the content. >>>=20 >>> Rgds >>> Shraddha >>>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >>> Sent: Monday, October 21, 2013 4:24 PM >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hannes Gredler; = Rob Shakir >>> Subject: New Version Notification for draft-hegde-ospf-node-admin-tag-0= 0.txt >>>=20 >>>=20 >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt >>> has been successfully submitted by Shraddha Hegde and posted to the IET= F repository. >>>=20 >>> Filename: draft-hegde-ospf-node-admin-tag >>> Revision: 00 >>> Title: Advertising per-node administrative tags in OSPF >>> Creation date: 2013-10-21 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL: http://www.ietf.org/internet-drafts/draft-hegde-ospf-n= ode-admin-tag-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-hegde-ospf-node-= admin-tag >>> Htmlized: http://tools.ietf.org/html/draft-hegde-ospf-node-admin= -tag-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes an extension to OSPF protocol [RFC2328] to >>> add an optional operational capability, that allows tagging and >>> grouping of the nodes in an OSPF domain. This allows >>> simplification,ease of management and control over route and path >>> selection based on configured policies. >>>=20 >>> This document describes the protocol extensions to disseminate per- >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=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 >>=20 >>=20 >=20 >=20 From hannes@juniper.net Mon Oct 21 06:52:14 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8E021F9AC1 for ; Mon, 21 Oct 2013 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW6jOIJUfosu for ; Mon, 21 Oct 2013 06:52:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9DB21F9D0E for ; Mon, 21 Oct 2013 06:52:07 -0700 (PDT) Received: from mail148-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 13:52:07 +0000 Received: from mail148-ch1 (localhost [127.0.0.1]) by mail148-ch1-R.bigfish.com (Postfix) with ESMTP id E49012004C; Mon, 21 Oct 2013 13:52:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI9371I936eI1454Ic430I542I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail148-ch1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail148-ch1 (localhost.localdomain [127.0.0.1]) by mail148-ch1 (MessageSwitch) id 1382363524581694_6403; Mon, 21 Oct 2013 13:52:04 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail148-ch1.bigfish.com (Postfix) with ESMTP id 897BC460050; Mon, 21 Oct 2013 13:52:04 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 13:52:04 +0000 Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 21 Oct 2013 13:51:59 +0000 Date: Mon, 21 Oct 2013 15:51:53 +0200 From: Hannes Gredler To: Acee Lindem Message-ID: <20131021135153.GA7872@juniper.net> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 13:52:14 -0000 On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: | Hannes, | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: | | > acee, | > | > why should we give an upper boundary on things which | > - might be subject to change and | > - which have a historic track record of being underestimated. | | You don't have to - just request a separate OSPFv2 opaque LSA and IPv6 OSPFv3 LSA from IANA. | Another alternative would be to extend the RI LSA to be multi-instance and relegate the variable length tags to an instance other than instance 0. again the question why i do have to ? i can perfectly fit in single-digit as well as a few dozens of colors in a single RI LSA - what is your concern - except that we may use inappropriate large space for TE ? any reasonable implementation SHOULD restrict the node color set, such that overwhelming the 64K of RI LSPs is not going to happen. | > the 'per-link' admin-groups serve as a good example here: | > initially conceived as "you won't ever need more than 32" we have | > now arrived at a variable length (unbounded) extension. | > | > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-00 | > | > for a humorous take to it, have a look at | > http://tools.ietf.org/html/rfc1925 | > rule (9) and (10) | > | > /hannes | > | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: | > | >> Hi Shraddha, | >> Since the size of the tag data is unbounded, could you either put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the size to some maximum number of tags, e.g., 16? | >> Thanks, | >> Acee | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: | >> | >>> Hi All, | >>> | >>> We have posted a draft on " Advertising per-node administrative tags in OSPF" and would like to hear your views on it. Please feel free to raise any suggestion/comment on the content. | >>> | >>> Rgds | >>> Shraddha | >>> | >>> -----Original Message----- | >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] | >>> Sent: Monday, October 21, 2013 4:24 PM | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hannes Gredler; Rob Shakir | >>> Subject: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt | >>> | >>> | >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt | >>> has been successfully submitted by Shraddha Hegde and posted to the IETF repository. | >>> | >>> Filename: draft-hegde-ospf-node-admin-tag | >>> Revision: 00 | >>> Title: Advertising per-node administrative tags in OSPF | >>> Creation date: 2013-10-21 | >>> Group: Individual Submission | >>> Number of pages: 6 | >>> URL: http://www.ietf.org/internet-drafts/draft-hegde-ospf-node-admin-tag-00.txt | >>> Status: http://datatracker.ietf.org/doc/draft-hegde-ospf-node-admin-tag | >>> Htmlized: http://tools.ietf.org/html/draft-hegde-ospf-node-admin-tag-00 | >>> | >>> | >>> Abstract: | >>> This document describes an extension to OSPF protocol [RFC2328] to | >>> add an optional operational capability, that allows tagging and | >>> grouping of the nodes in an OSPF domain. This allows | >>> simplification,ease of management and control over route and path | >>> selection based on configured policies. | >>> | >>> This document describes the protocol extensions to disseminate per- | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. | >>> | >>> | >>> | >>> | >>> | >>> 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 | >>> | >>> | >>> | >>> _______________________________________________ | >>> 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 acee.lindem@ericsson.com Mon Oct 21 07:10:14 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03D111E8573 for ; Mon, 21 Oct 2013 07:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVmcqdBeWqsP for ; Mon, 21 Oct 2013 07:10:08 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 969E111E83B4 for ; Mon, 21 Oct 2013 07:10:06 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-db-526535bd554d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A6.E6.03458.DB535625; Mon, 21 Oct 2013 16:10:06 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 10:10:05 -0400 From: Acee Lindem To: Hannes Gredler Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzkvgNHObxoS1x0Of7JHPuwEEI5n+/UtAgABniwCAAAPWAIAAAeCAgAAFT4CAAAUUgA== Date: Mon, 21 Oct 2013 14:10:04 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A027F@eusaamb101.ericsson.se> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> <20131021135153.GA7872@juniper.net> In-Reply-To: <20131021135153.GA7872@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030A027Feusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZXLonQXefaWqQQd9bPov+e0/YLJovbWa3 aLl3j91iz7u1jBY3Hu1ldmD1aPsymcljyZKfTB7Xm66yBzBHcdmkpOZklqUW6dslcGU8vf2L peBHQcXt9ROYGxhXxnUxcnJICJhInN/2lxXCFpO4cG89WxcjF4eQwFFGiT9HmhghnOWMEt/v XGYCqWIT0JF4/ugfM4gtIqAusXDSXWaQImaByYwSf/s2sHQxcnAIC2RK/L/uB2KKCGRJtK81 gSgPk9i++Q0TSJhFQFVi7019kDCvgK/E1s0HoVZ9YJI4OGsl2HhOAQOJXdvPsIPYjEDHfT+1 BuwEZgFxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/UM8oSyx5sp8Foj5f4sHuzYwQywQlTs58wjKB UXQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHUL3WEm9n9rAiq1nAyLGKkaO0OLUs N93IcBMjMCqPSbA57mBc8MnyEKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanFhxiZODil Ghgr4vWzXd04RW1tYjQ9/q1z49WIljngP0n029Et/h+v821mfmsVOGP+nCdLHWu01lkz/fwR ev/XqkVF1x1Snkn/5vXtfVej+PPeSV7W7xcjGF9NXrtnU2EiW2A/r+WHsFkFdTM+NMzyaDqZ af94llm1cehKg7BsrS98jkvOb2ic+OnLdjdRrldKLMUZiYZazEXFiQDkQL/wmAIAAA== Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 14:10:14 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030A027Feusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: | Hannes, | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: | | > acee, | > | > why should we give an upper boundary on things which | > - might be subject to change and | > - which have a historic track record of being underestimated. | | You don't have to - just request a separate OSPFv2 opaque LSA and IPv6 OS= PFv3 LSA from IANA. | Another alternative would be to extend the RI LSA to be multi-instance an= d relegate the variable length tags to an instance other than instance 0. again the question why i do have to ? i can perfectly fit in single-digit as well as a few dozens of colors in a = single RI LSA - what is your concern - except that we may use inappropriate large space f= or TE ? any reasonable implementation SHOULD restrict the node color set, such that overwhelming the 64K of RI LSPs is not going to happen. We don't want a standard that leaves room for "unreasonable" implementation= s ;^). I think the policy in RFC 4970 is clear. Here is an excerpt: 3. Router Information LSA Opaque Usage and Applicability 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. The intent is to both limit the size of the RI LSA to the point where an OSPF router will always be able to contain the TLVs in a single LSA and to keep the task of determining what has changed between LSA instances reasonably simple. Hence, discretion and sound engineering judgment will need to be applied when deciding whether newly proposed TLV(s) in support of a new application are advertised in the RI LSA or warrant the creation of an application specific LSA. Anyway, this hasn't even been presented or accepted as a WG document. Thanks, Acee | > the 'per-link' admin-groups serve as a good example here: | > initially conceived as "you won't ever need more than 32" we have | > now arrived at a variable length (unbounded) extension. | > | > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-00 | > | > for a humorous take to it, have a look at | > http://tools.ietf.org/html/rfc1925 | > rule (9) and (10) | > | > /hannes | > | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: | > | >> Hi Shraddha, | >> Since the size of the tag data is unbounded, could you either put it i= n a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the size to some max= imum number of tags, e.g., 16? | >> Thanks, | >> Acee | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: | >> | >>> Hi All, | >>> | >>> We have posted a draft on " Advertising per-node administrative tags = in OSPF" and would like to hear your views on it. Please feel free to raise= any suggestion/comment on the content. | >>> | >>> Rgds | >>> Shraddha | >>> | >>> -----Original Message----- | >>> From: internet-drafts@ietf.org [mail= to:internet-drafts@ietf.org] | >>> Sent: Monday, October 21, 2013 4:24 PM | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hannes Gredler= ; Rob Shakir | >>> Subject: New Version Notification for draft-hegde-ospf-node-admin-tag= -00.txt | >>> | >>> | >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt | >>> has been successfully submitted by Shraddha Hegde and posted to the I= ETF repository. | >>> | >>> Filename: draft-hegde-ospf-node-admin-tag | >>> Revision: 00 | >>> Title: Advertising per-node administrative tags in OSPF | >>> Creation date: 2013-10-21 | >>> Group: Individual Submission | >>> Number of pages: 6 | >>> URL: http://www.ietf.org/internet-drafts/draft-hegde-ospf= -node-admin-tag-00.txt | >>> Status: http://datatracker.ietf.org/doc/draft-hegde-ospf-nod= e-admin-tag | >>> Htmlized: http://tools.ietf.org/html/draft-hegde-ospf-node-adm= in-tag-00 | >>> | >>> | >>> Abstract: | >>> This document describes an extension to OSPF protocol [RFC2328] to | >>> add an optional operational capability, that allows tagging and | >>> grouping of the nodes in an OSPF domain. This allows | >>> simplification,ease of management and control over route and path | >>> selection based on configured policies. | >>> | >>> This document describes the protocol extensions to disseminate per- | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. | >>> | >>> | >>> | >>> | >>> | >>> Please note that it may take a couple of minutes from the time of sub= mission until the htmlized version and diff are available at tools.ietf.org= . | >>> | >>> The IETF Secretariat | >>> | >>> | >>> | >>> _______________________________________________ | >>> 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 | >> | >> | > | > | | | --_000_94A203EA12AECE4BA92D42DBFFE0AE47030A027Feusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <53DAD1AAA768FE4488681E4B83F867C4@ericsson.com> Content-Transfer-Encoding: quoted-printable
On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote:

On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote:
| Hannes,
|
| On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote:
|
| > acee,
| >
| > why should we give an upper boundary on things which
| > - might be subject to change and
| > - which have a historic track record of being underestimated.
|
| You don't have to - just request a separate OSPFv2 opaque LSA and IPv6 OS= PFv3 LSA from IANA.
| Another alternative would be to extend the RI LSA to be multi-instance an= d relegate the variable length tags to an instance other than instance 0.

again the question why i do have to ?
i can perfectly fit in single-digit as well as a few dozens of colors in a = single RI LSA
- what is your concern - except that we may use inappropriate large space f= or TE ?
any reasonable implementation SHOULD restrict the node color set, such
that overwhelming the 64K of RI LSPs is not going to happen.

We don't want a standard that leaves room for "unreasonable"= implementations ;^). I think the policy in RFC 4970 is clear. Here is an e= xcerpt:

3.  Router Information LSA Opaque Usage and Applicability<= /div>

   The purpose of the Router Information (RI) LSA is to a= dvertise
   information relating to the aggregate OSPF router. &nb= sp;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.  The intent is to both limit the siz= e of the RI LSA to
   the point where an OSPF router will always be able to = contain the
   TLVs in a single LSA and to keep the task of determini= ng what has
   changed between LSA instances reasonably simple.  = ;Hence, discretion
   and sound engineering judgment will need to be applied= when deciding
   whether newly proposed TLV(s) in support of a new appl= ication are
   advertised in the RI LSA or warrant the creation of an= application
   specific LSA.


Anyway, this hasn't even been presented or accepted as a WG document.&= nbsp;

Thanks,
Acee


| > the 'per-link' admin-groups serve as a good example here:
| > initially conceived as "you won't ever need more than 32" = we have
| > now arrived at a variable length (unbounded) extension.
| >
| > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-00<= br> | >
| > for a humorous take to it, have a look at
| > http://tools.ietf.org= /html/rfc1925
| > rule (9) and (10)
| >
| > /hannes
| >
| > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote:
| >
| >> Hi Shraddha,
| >> Since the size of the tag data is unbounded, could you either pu= t it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the size to so= me maximum number of tags, e.g., 16?  
| >> Thanks,
| >> Acee
| >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote:
| >>
| >>> Hi All,
| >>>
| >>> We have posted a draft on " Advertising per-node admini= strative tags in OSPF" and would like to hear your views on it. Please= feel free to raise any suggestion/comment on the content.
| >>>
| >>> Rgds
| >>> Shraddha
| >>>
| >>> -----Original Message-----
| >>> From: internet-d= rafts@ietf.org [mailto:internet-drafts@ietf.org]
| >>> Sent: Monday, October 21, 2013 4:24 PM
| >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hanne= s Gredler; Rob Shakir
| >>> Subject: New Version Notification for draft-hegde-ospf-node-= admin-tag-00.txt
| >>>
| >>>
| >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt=
| >>> has been successfully submitted by Shraddha Hegde and posted= to the IETF repository.
| >>>
| >>> Filename: draft-hegde-ospf-node-admin-tag
| >>> Revision: 00
| >>> Title: = Advertising per-node administrative tags in OSPF
| >>> Creation date: 2013-10-21
| >>> Group: = Individual Submission
| >>> Number of pages: 6
| >>> URL:          &= nbsp;  http://www.ietf.org/internet-drafts/draft-hegd= e-ospf-node-admin-tag-00.txt
| >>> Status:         &nbs= p;http://datatracker.ietf.org/doc/draft-hegde-ospf-node-admin-tag
| >>> Htmlized:        http://t= ools.ietf.org/html/draft-hegde-ospf-node-admin-tag-00
| >>>
| >>>
| >>> Abstract:
| >>> This document describes an extension to OSPF protocol [RFC23= 28] to
| >>> add an optional operational capability, that allows tagging = and
| >>> grouping of the nodes in an OSPF domain.  This allows | >>> simplification,ease of management and control over route and= path
| >>> selection based on configured policies.
| >>>
| >>> This document describes the protocol extensions to dissemina= te per-
| >>> node admin-tags to the OSPFv2 and OSPFv3 protocols.
| >>>
| >>>
| >>>
| >>>
| >>>
| >>> Please note that it may take a couple of minutes from the ti= me of submission until the htmlized version and diff are available at tools.ietf.org.
| >>>
| >>> The IETF Secretariat
| >>>
| >>>
| >>>
| >>> _______________________________________________
| >>> OSPF mailing list
| >>> OSPF@ietf.org
| >>> https= ://www.ietf.org/mailman/listinfo/ospf
| >>
| >> _______________________________________________
| >> OSPF mailing list
| >> OSPF@ietf.org
| >> https://w= ww.ietf.org/mailman/listinfo/ospf
| >>
| >>
| >
| >
|
|
|


--_000_94A203EA12AECE4BA92D42DBFFE0AE47030A027Feusaamb101erics_-- From hannes@juniper.net Mon Oct 21 08:09:48 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AF011E8401 for ; Mon, 21 Oct 2013 08:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcad6yfezlFd for ; Mon, 21 Oct 2013 08:09:35 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 12DDB11E81DE for ; Mon, 21 Oct 2013 08:09:03 -0700 (PDT) Received: from mail106-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE014.bigfish.com (10.236.130.77) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 15:08:58 +0000 Received: from mail106-co9 (localhost [127.0.0.1]) by mail106-co9-R.bigfish.com (Postfix) with ESMTP id 254742008E; Mon, 21 Oct 2013 15:08:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz98dI9371I936eI1454I146fIc430I542I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail106-co9: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail106-co9 (localhost.localdomain [127.0.0.1]) by mail106-co9 (MessageSwitch) id 1382368136904605_17275; Mon, 21 Oct 2013 15:08:56 +0000 (UTC) Received: from CO9EHSMHS027.bigfish.com (unknown [10.236.132.242]) by mail106-co9.bigfish.com (Postfix) with ESMTP id D780E320031; Mon, 21 Oct 2013 15:08:56 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by CO9EHSMHS027.bigfish.com (10.236.130.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 15:08:56 +0000 Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 21 Oct 2013 15:08:53 +0000 Date: Mon, 21 Oct 2013 17:08:47 +0200 From: Hannes Gredler To: Acee Lindem Message-ID: <20131021150847.GA7980@juniper.net> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> <20131021135153.GA7872@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A027F@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A027F@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.54.36] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 15:09:48 -0000 On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: |=20 | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: |=20 | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: | | Hannes, | | | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: | | | | > acee, | | > | | > why should we give an upper boundary on things which | | > - might be subject to change and | | > - which have a historic track record of being underestimated. | | | | You don't have to - just request a separate OSPFv2 opaque LSA an= d | IPv6 OSPFv3 LSA from IANA. | | Another alternative would be to extend the RI LSA to be multi- | instance and relegate the variable length tags to an instance othe= r | than instance 0. |=20 | again the question why i do have to ? | i can perfectly fit in single-digit as well as a few dozens of col= ors | in a single RI LSA | - what is your concern - except that we may use inappropriate larg= e | space for TE ? | any reasonable implementation SHOULD restrict the node color set, | such | that overwhelming the 64K of RI LSPs is not going to happen. |=20 | We don't want a standard that leaves room for "unreasonable" | implementations ;^). I think the policy in RFC 4970 is clear. Here is a= n | excerpt: oh boy - i wish i could let the non-sense disappear just with good standard docs ;-) - but i hear you - so all you're asking for is an upper boundary ? - is 128 low enough to not scare you and be compliant to the below paragraph. =20 | 3. =A0Router Information LSA Opaque Usage and Applicability |=20 | =A0 =A0The purpose of the Router Information (RI) LSA is to advertise | =A0 =A0information relating to the aggregate OSPF router. =A0Normally, = this | =A0 =A0should be confined to TLVs with a single value or very few value= s. | =A0 =A0It is not meant to be a generic container to carry any and all | =A0 =A0information. =A0The intent is to both limit the size of the RI L= SA to | =A0 =A0the point where an OSPF router will always be able to contain th= e | =A0 =A0TLVs in a single LSA and to keep the task of determining what ha= s | =A0 =A0changed between LSA instances reasonably simple. =A0Hence, discr= etion | =A0 =A0and sound engineering judgment will need to be applied when deci= ding | =A0 =A0whether newly proposed TLV(s) in support of a new application ar= e | =A0 =A0advertised in the RI LSA or warrant the creation of an applicati= on | =A0 =A0specific LSA. |=20 |=20 | Anyway, this hasn't even been presented or accepted as a WG document.=A0 which is not a reason why we should not discuss how to iron out the bumpy= parts now. thanks ! /hannes | | > the 'per-link' admin-groups serve as a good example here: | | > initially conceived as "you won't ever need more than | 32" we have | | > now arrived at a variable length (unbounded) extension. | | > | | > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- | groups-00 | | > | | > for a humorous take to it, have a look at | | > http://tools.ietf.org/html/rfc1925 | | > rule (9) and (10) | | > | | > /hannes | | > | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: | | > | | >> Hi Shraddha, | | >> Since the size of the tag data is unbounded, could you either | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the | size to some maximum number of tags, e.g., 16? =A0 | | >> Thanks, | | >> Acee | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: | | >> | | >>> Hi All, | | >>> | | >>> We have posted a draft on " Advertising per-node | administrative tags in OSPF" and would like to hear your view= s | on it. Please feel free to raise any suggestion/comment on the | content. | | >>> | | >>> Rgds | | >>> Shraddha | | >>> | | >>> -----Original Message----- | | >>> From: internet-drafts@ietf.org [mailto:internet- | drafts@ietf.org] | | >>> Sent: Monday, October 21, 2013 4:24 PM | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hanne= s | Gredler; Rob Shakir | | >>> Subject: New Version Notification for draft-hegde-ospf-node- | admin-tag-00.txt | | >>> | | >>> | | >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt | | >>> has been successfully submitted by Shraddha Hegde and posted= to | the IETF repository. | | >>> | | >>> Filename: draft-hegde-ospf-node-admin-tag | | >>> Revision: 00 | | >>> Title: Advertising per-node administrative tags in OSPF | | >>> Creation date: 2013-10-21 | | >>> Group: Individual Submission | | >>> Number of pages: 6 | | >>> URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org= /internet-drafts/draft- | hegde-ospf-node-admin-tag-00.txt | | >>> Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0http://datatracker.ietf.o= rg/doc/draft-hegde- | ospf-node-admin-tag | | >>> Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/dr= aft-hegde-ospf- | node-admin-tag-00 | | >>> | | >>> | | >>> Abstract: | | >>> This document describes an extension to OSPF protocol [RFC23= 28] | to | | >>> add an optional operational capability, that allows tagging = and | | >>> grouping of the nodes in an OSPF domain. =A0This allows | | >>> simplification,ease of management and control over route and | path | | >>> selection based on configured policies. | | >>> | | >>> This document describes the protocol extensions to dissemina= te | per- | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. | | >>> | | >>> | | >>> | | >>> | | >>> | | >>> Please note that it may take a couple of minutes from the ti= me | of submission until the htmlized version and diff are available at | tools.ietf.org. | | >>> | | >>> The IETF Secretariat | | >>> | | >>> | | >>> | | >>> _______________________________________________ | | >>> 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 | | >> | | >> | | > | | > | | | | | | |=20 |=20 From acee@lindem.com Mon Oct 21 08:24:49 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDC921F9A8D for ; Mon, 21 Oct 2013 08:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atOqRrFhHNAZ for ; Mon, 21 Oct 2013 08:24:43 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id B892611E81D3 for ; Mon, 21 Oct 2013 08:24:42 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=AOHYjtsI c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=r5VoNJ4UmnsA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=cln1f0h_RF4A:10 a=48vgC7mUAAAA:8 a=ayC55rCoAAAA:8 a=uMSBuXpSb8vDAXup2lgA:9 a=CjuIK1q_8ugA:10 a=E6k37eg1NvgA:10 a=lZB815dzVvQA:10 a=kArU_8CLA2fducO-:21 a=Nhk3TMI9k8O_9pl3:21 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:63885] helo=[192.168.1.106]) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 04/1F-18682-93745625; Mon, 21 Oct 2013 15:24:41 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <20131021150847.GA7980@juniper.net> Date: Mon, 21 Oct 2013 11:24:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> <20131021135153.GA7872@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A027F@eusaamb101.ericsson.se> <20131021150847.GA7980@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1085) Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 15:24:49 -0000 On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: > On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: > |=20 > | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: > |=20 > | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: > | | Hannes, > | | > | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: > | | > | | > acee, > | | > > | | > why should we give an upper boundary on things which > | | > - might be subject to change and > | | > - which have a historic track record of being = underestimated. > | | > | | You don't have to - just request a separate OSPFv2 opaque LSA = and > | IPv6 OSPFv3 LSA from IANA. > | | Another alternative would be to extend the RI LSA to be = multi- > | instance and relegate the variable length tags to an instance = other > | than instance 0. > |=20 > | again the question why i do have to ? > | i can perfectly fit in single-digit as well as a few dozens of = colors > | in a single RI LSA > | - what is your concern - except that we may use inappropriate = large > | space for TE ? > | any reasonable implementation SHOULD restrict the node color = set, > | such > | that overwhelming the 64K of RI LSPs is not going to happen. > |=20 > | We don't want a standard that leaves room for = "unreasonable" > | implementations ;^). I think the policy in RFC 4970 is clear. Here = is an > | excerpt: >=20 > oh boy - i wish i could let the non-sense disappear just with good > standard docs ;-) - but i hear you - so all you're asking for is an > upper boundary ? - is 128 low enough to not scare you and > be compliant to the below paragraph. Actually, I think separate LSAs is a better alternative.=20 >=20 > | 3. Router Information LSA Opaque Usage and Applicability > |=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. The intent is to both limit the size of the RI LSA = to > | the point where an OSPF router will always be able to contain the > | TLVs in a single LSA and to keep the task of determining what has > | changed between LSA instances reasonably simple. Hence, = discretion > | and sound engineering judgment will need to be applied when = deciding > | whether newly proposed TLV(s) in support of a new application are > | advertised in the RI LSA or warrant the creation of an = application > | specific LSA. > |=20 > |=20 > | Anyway, this hasn't even been presented or accepted as a WG = document.=20 >=20 > which is not a reason why we should not discuss how to iron out the = bumpy parts now. Right. Thanks, Acee=20 >=20 > thanks ! >=20 > /hannes >=20 > | | > the 'per-link' admin-groups serve as a good example here: > | | > initially conceived as "you won't ever need more than > | 32" we have > | | > now arrived at a variable length (unbounded) extension. > | | > > | | > = http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- > | groups-00 > | | > > | | > for a humorous take to it, have a look at > | | > http://tools.ietf.org/html/rfc1925 > | | > rule (9) and (10) > | | > > | | > /hannes > | | > > | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: > | | > > | | >> Hi Shraddha, > | | >> Since the size of the tag data is unbounded, could you = either > | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit = the > | size to some maximum number of tags, e.g., 16? =20 > | | >> Thanks, > | | >> Acee > | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: > | | >> > | | >>> Hi All, > | | >>> > | | >>> We have posted a draft on " Advertising per-node > | administrative tags in OSPF" and would like to hear your = views > | on it. Please feel free to raise any suggestion/comment on the > | content. > | | >>> > | | >>> Rgds > | | >>> Shraddha > | | >>> > | | >>> -----Original Message----- > | | >>> From: internet-drafts@ietf.org [mailto:internet- > | drafts@ietf.org] > | | >>> Sent: Monday, October 21, 2013 4:24 PM > | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; = Hannes > | Gredler; Rob Shakir > | | >>> Subject: New Version Notification for = draft-hegde-ospf-node- > | admin-tag-00.txt > | | >>> > | | >>> > | | >>> A new version of I-D, = draft-hegde-ospf-node-admin-tag-00.txt > | | >>> has been successfully submitted by Shraddha Hegde and = posted to > | the IETF repository. > | | >>> > | | >>> Filename: draft-hegde-ospf-node-admin-tag > | | >>> Revision: 00 > | | >>> Title: Advertising per-node administrative tags in OSPF > | | >>> Creation date: 2013-10-21 > | | >>> Group: Individual Submission > | | >>> Number of pages: 6 > | | >>> URL: = http://www.ietf.org/internet-drafts/draft- > | hegde-ospf-node-admin-tag-00.txt > | | >>> Status: = http://datatracker.ietf.org/doc/draft-hegde- > | ospf-node-admin-tag > | | >>> Htmlized: = http://tools.ietf.org/html/draft-hegde-ospf- > | node-admin-tag-00 > | | >>> > | | >>> > | | >>> Abstract: > | | >>> This document describes an extension to OSPF protocol = [RFC2328] > | to > | | >>> add an optional operational capability, that allows = tagging and > | | >>> grouping of the nodes in an OSPF domain. This allows > | | >>> simplification,ease of management and control over route = and > | path > | | >>> selection based on configured policies. > | | >>> > | | >>> This document describes the protocol extensions to = disseminate > | per- > | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. > | | >>> > | | >>> > | | >>> > | | >>> > | | >>> > | | >>> 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 > | | >>> > | | >>> > | | >>> > | | >>> _______________________________________________ > | | >>> 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 > | | >> > | | >> > | | > > | | > > | | > | | > | | > |=20 > |=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From shraddha@juniper.net Mon Oct 21 12:13:34 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7C611E83BD for ; Mon, 21 Oct 2013 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFKeV63Gh70L for ; Mon, 21 Oct 2013 12:13:25 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id A7D1011E8242 for ; Mon, 21 Oct 2013 12:12:44 -0700 (PDT) Received: from mail159-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 19:12:44 +0000 Received: from mail159-va3 (localhost [127.0.0.1]) by mail159-va3-R.bigfish.com (Postfix) with ESMTP id CD50C30014E; Mon, 21 Oct 2013 19:12:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI9371I936eI1454I146fIc430I542I1432I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail159-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shraddha@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(52314003)(24454002)(53754006)(51704005)(502244003)(13464003)(52044002)(164054003)(199002)(189002)(377454003)(377424004)(19580395003)(83322001)(56776001)(54316002)(19580405001)(81686001)(80022001)(66066001)(80976001)(46102001)(63696002)(65816001)(76482001)(69226001)(81816001)(51856001)(15975445006)(81342001)(79102001)(77982001)(59766001)(81542001)(74316001)(74706001)(74876001)(1941001)(15202345003)(83072001)(74366001)(74502001)(47446002)(85306002)(74662001)(31966008)(76796001)(4396001)(76576001)(49866001)(56816003)(47736001)(76786001)(33646001)(50986001)(47976001)(53806001)(77096001)(54356001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB127.namprd05.prod.outlook.com; CLIP:116.197.178.83; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:; Received: from mail159-va3 (localhost.localdomain [127.0.0.1]) by mail159-va3 (MessageSwitch) id 1382382761411339_23965; Mon, 21 Oct 2013 19:12:41 +0000 (UTC) Received: from VA3EHSMHS046.bigfish.com (unknown [10.7.14.226]) by mail159-va3.bigfish.com (Postfix) with ESMTP id 5E89E4E004A; Mon, 21 Oct 2013 19:12:41 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS046.bigfish.com (10.7.99.56) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 19:12:41 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 21 Oct 2013 19:12:40 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 21 Oct 2013 19:12:37 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.230]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.230]) with mapi id 15.00.0785.001; Mon, 21 Oct 2013 19:12:36 +0000 From: Shraddha Hegde To: Acee Lindem , Hannes Gredler Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOznHdHMmWlADk7k+I4LaGZmh7PZn/ggyw Date: Mon, 21 Oct 2013 19:12:36 +0000 Message-ID: References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> <20131021135153.GA7872@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A027F@eusaamb101.ericsson.se> <20131021150847.GA7980@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.83] x-forefront-prvs: 00064751B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 19:13:34 -0000 Actually, I think separate LSAs is a better alternative. Node-tag is a just another property of the node. OSPFv2/v3 have = achieved the desired functionality using numerous link/node properties usin= g TLVs in TE-LSA so I don't see an absolute necessity of going with a new LSA.=20 Rgds Shraddha -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Monday, October 21, 2013 8:55 PM To: Hannes Gredler Cc: OSPF List; Rob Shakir; Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegd= e-ospf-node-admin-tag-00.txt On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: > On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: > |=20 > | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: > |=20 > | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: > | | Hannes, > | | > | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: > | | > | | > acee, > | | > > | | > why should we give an upper boundary on things which > | | > - might be subject to change and > | | > - which have a historic track record of being underestimated. > | | > | | You don't have to - just request a separate OSPFv2 opaque LSA an= d > | IPv6 OSPFv3 LSA from IANA. > | | Another alternative would be to extend the RI LSA to be multi- > | instance and relegate the variable length tags to an instance othe= r > | than instance 0. > |=20 > | again the question why i do have to ? > | i can perfectly fit in single-digit as well as a few dozens of col= ors > | in a single RI LSA > | - what is your concern - except that we may use inappropriate larg= e > | space for TE ? > | any reasonable implementation SHOULD restrict the node color set, > | such > | that overwhelming the 64K of RI LSPs is not going to happen. > |=20 > | We don't want a standard that leaves room for=20 > | "unreasonable" implementations ;^). I think the policy in=20 > | RFC 4970 is clear. Here is an > | excerpt: >=20 > oh boy - i wish i could let the non-sense disappear just with good=20 > standard docs ;-) - but i hear you - so all you're asking for is an=20 > upper boundary ? - is 128 low enough to not scare you and be compliant=20 > to the below paragraph. Actually, I think separate LSAs is a better alternative.=20 >=20 > | 3. Router Information LSA Opaque Usage and Applicability > |=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. The intent is to both limit the size of the RI LSA to > | the point where an OSPF router will always be able to contain the > | TLVs in a single LSA and to keep the task of determining what has > | changed between LSA instances reasonably simple. Hence, discretion > | and sound engineering judgment will need to be applied when deciding > | whether newly proposed TLV(s) in support of a new application are > | advertised in the RI LSA or warrant the creation of an application > | specific LSA. > |=20 > |=20 > | Anyway, this hasn't even been presented or accepted as a WG document.=20 >=20 > which is not a reason why we should not discuss how to iron out the bumpy= parts now. Right. Thanks, Acee=20 >=20 > thanks ! >=20 > /hannes >=20 > | | > the 'per-link' admin-groups serve as a good example here: > | | > initially conceived as "you won't ever need more than > | 32" we have > | | > now arrived at a variable length (unbounded) extension. > | | > > | | > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- > | groups-00 > | | > > | | > for a humorous take to it, have a look at > | | > http://tools.ietf.org/html/rfc1925 > | | > rule (9) and (10) > | | > > | | > /hannes > | | > > | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: > | | > > | | >> Hi Shraddha, > | | >> Since the size of the tag data is unbounded, could you either > | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the > | size to some maximum number of tags, e.g., 16? =20 > | | >> Thanks, > | | >> Acee > | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: > | | >> > | | >>> Hi All, > | | >>> > | | >>> We have posted a draft on " Advertising per-node > | administrative tags in OSPF" and would like to hear your view= s > | on it. Please feel free to raise any suggestion/comment on the > | content. > | | >>> > | | >>> Rgds > | | >>> Shraddha > | | >>> > | | >>> -----Original Message----- > | | >>> From: internet-drafts@ietf.org [mailto:internet- > | drafts@ietf.org] > | | >>> Sent: Monday, October 21, 2013 4:24 PM > | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hanne= s > | Gredler; Rob Shakir > | | >>> Subject: New Version Notification for draft-hegde-ospf-node- > | admin-tag-00.txt > | | >>> > | | >>> > | | >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt > | | >>> has been successfully submitted by Shraddha Hegde and posted= to > | the IETF repository. > | | >>> > | | >>> Filename: draft-hegde-ospf-node-admin-tag > | | >>> Revision: 00 > | | >>> Title: Advertising per-node administrative tags in OSPF > | | >>> Creation date: 2013-10-21 > | | >>> Group: Individual Submission > | | >>> Number of pages: 6 > | | >>> URL: http://www.ietf.org/internet-drafts/draft- > | hegde-ospf-node-admin-tag-00.txt > | | >>> Status: http://datatracker.ietf.org/doc/draft-hegde= - > | ospf-node-admin-tag > | | >>> Htmlized: http://tools.ietf.org/html/draft-hegde-ospf= - > | node-admin-tag-00 > | | >>> > | | >>> > | | >>> Abstract: > | | >>> This document describes an extension to OSPF protocol [RFC23= 28] > | to > | | >>> add an optional operational capability, that allows tagging = and > | | >>> grouping of the nodes in an OSPF domain. This allows > | | >>> simplification,ease of management and control over route and > | path > | | >>> selection based on configured policies. > | | >>> > | | >>> This document describes the protocol extensions to dissemina= te > | per- > | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. > | | >>> > | | >>> > | | >>> > | | >>> > | | >>> > | | >>> Please note that it may take a couple of minutes from the ti= me > | of submission until the htmlized version and diff are available at > | tools.ietf.org. > | | >>> > | | >>> The IETF Secretariat > | | >>> > | | >>> > | | >>> > | | >>> _______________________________________________ > | | >>> 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 > | | >> > | | >> > | | > > | | > > | | > | | > | | > |=20 > |=20 >=20 > _______________________________________________ > 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 acee.lindem@ericsson.com Mon Oct 21 12:23:11 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4778C11E8237 for ; Mon, 21 Oct 2013 12:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HzvgGm9hYA8 for ; Mon, 21 Oct 2013 12:23:05 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEE011E8600 for ; Mon, 21 Oct 2013 12:23:00 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-32-52657f13dcae Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AF.AB.09414.31F75625; Mon, 21 Oct 2013 21:23:00 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 15:22:59 -0400 From: Acee Lindem To: Shraddha Hegde Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzpG2MZ1Oa1oSk0Wln+nocpUZIJn/y84A Date: Mon, 21 Oct 2013 19:22:58 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A1B71@eusaamb101.ericsson.se> References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> <20131021135153.GA7872@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A027F@eusaamb101.ericsson.se> <20131021150847.GA7980@juniper.net> 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.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <326CB04C23B73A4DB961EC0E973F2254@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZXLonVlekPjXI4E+roMW0W9PZLPrvPWGz aL60md2i5d49dos979YyWtx4tJfZgc2j7ctkJo8lS34yeVxvusru8WHRBdYAligum5TUnMyy 1CJ9uwSujL9T0wsmu1RMODmfqYHxr0EXIyeHhICJxOmuyewQtpjEhXvr2boYuTiEBI4ySrw9 /4IRwlnOKDGtdRIbSBWbgI7E80f/mEFsEQFNiWsTn7KCFDELbGKU6NnXwwSSEBbIlNi7axcL RFGWxJW9kxghbCOJl78XgNWwCKhKfP3QCWbzCvhKnJh1hhli2y0WiZtfVoFt4BQIk3i48BTY Zkag+76fWgPWwCwgLnHryXwmiLsFJJbsOc8MYYtKvHz8jxXCVpZY8mQ/C0S9jsSC3Z/YIGxr iYZHVxghbG2JZQtfM0McIShxcuYTlgmM4rOQrJiFpH0WkvZZSNpnIWlfwMi6ipGjtDi1LDfd yGATIzAqj0mw6e5g3PPS8hCjNAeLkjjvl7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY W6acsZj5J2z92aPCvxa6X6+pOrxDyu+hy8zNN8rmitzZ/Yhv2+HL39Z/25rAfT2f3VtH/8zx c/Iy9SedGu9febYhyT1GoqgvUZqBT2v3K5GWrF4pjilhT0TKZ3IxuzrdZMopVD6WuuZKx3aJ MxN7LS57PCpwrm9NXcymkf3rheum3h/9q+6mKrEUZyQaajEXFScCAIF4WLiYAgAA Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 19:23:11 -0000 On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: > Actually, I think separate LSAs is a better alternative. >=20 > Node-tag is a just another property of the node. OSPFv2/v3 hav= e achieved the desired functionality using numerous link/node properties us= ing TLVs in TE-LSA so > I don't see an absolute necessity of going with a new LSA.=20 Shraddha - If you think the Router-Information LSA is the same as the TE LS= A you have not read RFC 4970.=20 Acee=20 >=20 > Rgds > Shraddha >=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of A= cee Lindem > Sent: Monday, October 21, 2013 8:55 PM > To: Hannes Gredler > Cc: OSPF List; Rob Shakir; Harish Raghuveer > Subject: Re: [OSPF] Review Request: New Version Notification for draft-he= gde-ospf-node-admin-tag-00.txt >=20 >=20 > On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: >=20 >> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: >> |=20 >> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: >> |=20 >> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: >> | | Hannes, >> | | >> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: >> | | >> | | > acee, >> | | > >> | | > why should we give an upper boundary on things which >> | | > - might be subject to change and >> | | > - which have a historic track record of being underestimated. >> | | >> | | You don't have to - just request a separate OSPFv2 opaque LSA a= nd >> | IPv6 OSPFv3 LSA from IANA. >> | | Another alternative would be to extend the RI LSA to be multi- >> | instance and relegate the variable length tags to an instance oth= er >> | than instance 0. >> |=20 >> | again the question why i do have to ? >> | i can perfectly fit in single-digit as well as a few dozens of co= lors >> | in a single RI LSA >> | - what is your concern - except that we may use inappropriate lar= ge >> | space for TE ? >> | any reasonable implementation SHOULD restrict the node color set, >> | such >> | that overwhelming the 64K of RI LSPs is not going to happen. >> |=20 >> | We don't want a standard that leaves room for=20 >> | "unreasonable" implementations ;^). I think the policy in=20 >> | RFC 4970 is clear. Here is an >> | excerpt: >>=20 >> oh boy - i wish i could let the non-sense disappear just with good=20 >> standard docs ;-) - but i hear you - so all you're asking for is an=20 >> upper boundary ? - is 128 low enough to not scare you and be compliant=20 >> to the below paragraph. >=20 > Actually, I think separate LSAs is a better alternative.=20 >=20 >=20 >=20 >>=20 >> | 3. Router Information LSA Opaque Usage and Applicability >> |=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. The intent is to both limit the size of the RI LSA to >> | the point where an OSPF router will always be able to contain the >> | TLVs in a single LSA and to keep the task of determining what has >> | changed between LSA instances reasonably simple. Hence, discretion >> | and sound engineering judgment will need to be applied when decidin= g >> | whether newly proposed TLV(s) in support of a new application are >> | advertised in the RI LSA or warrant the creation of an application >> | specific LSA. >> |=20 >> |=20 >> | Anyway, this hasn't even been presented or accepted as a WG document.= =20 >>=20 >> which is not a reason why we should not discuss how to iron out the bump= y parts now. >=20 > Right. >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> thanks ! >>=20 >> /hannes >>=20 >> | | > the 'per-link' admin-groups serve as a good example here: >> | | > initially conceived as "you won't ever need more than >> | 32" we have >> | | > now arrived at a variable length (unbounded) extension. >> | | > >> | | > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- >> | groups-00 >> | | > >> | | > for a humorous take to it, have a look at >> | | > http://tools.ietf.org/html/rfc1925 >> | | > rule (9) and (10) >> | | > >> | | > /hannes >> | | > >> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: >> | | > >> | | >> Hi Shraddha, >> | | >> Since the size of the tag data is unbounded, could you eithe= r >> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit th= e >> | size to some maximum number of tags, e.g., 16? =20 >> | | >> Thanks, >> | | >> Acee >> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >> | | >> >> | | >>> Hi All, >> | | >>> >> | | >>> We have posted a draft on " Advertising per-node >> | administrative tags in OSPF" and would like to hear your vie= ws >> | on it. Please feel free to raise any suggestion/comment on the >> | content. >> | | >>> >> | | >>> Rgds >> | | >>> Shraddha >> | | >>> >> | | >>> -----Original Message----- >> | | >>> From: internet-drafts@ietf.org [mailto:internet- >> | drafts@ietf.org] >> | | >>> Sent: Monday, October 21, 2013 4:24 PM >> | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hann= es >> | Gredler; Rob Shakir >> | | >>> Subject: New Version Notification for draft-hegde-ospf-node= - >> | admin-tag-00.txt >> | | >>> >> | | >>> >> | | >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.tx= t >> | | >>> has been successfully submitted by Shraddha Hegde and poste= d to >> | the IETF repository. >> | | >>> >> | | >>> Filename: draft-hegde-ospf-node-admin-tag >> | | >>> Revision: 00 >> | | >>> Title: Advertising per-node administrative tags in OSPF >> | | >>> Creation date: 2013-10-21 >> | | >>> Group: Individual Submission >> | | >>> Number of pages: 6 >> | | >>> URL: http://www.ietf.org/internet-drafts/draft- >> | hegde-ospf-node-admin-tag-00.txt >> | | >>> Status: http://datatracker.ietf.org/doc/draft-hegd= e- >> | ospf-node-admin-tag >> | | >>> Htmlized: http://tools.ietf.org/html/draft-hegde-osp= f- >> | node-admin-tag-00 >> | | >>> >> | | >>> >> | | >>> Abstract: >> | | >>> This document describes an extension to OSPF protocol [RFC2= 328] >> | to >> | | >>> add an optional operational capability, that allows tagging= and >> | | >>> grouping of the nodes in an OSPF domain. This allows >> | | >>> simplification,ease of management and control over route an= d >> | path >> | | >>> selection based on configured policies. >> | | >>> >> | | >>> This document describes the protocol extensions to dissemin= ate >> | per- >> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. >> | | >>> >> | | >>> >> | | >>> >> | | >>> >> | | >>> >> | | >>> Please note that it may take a couple of minutes from the t= ime >> | of submission until the htmlized version and diff are available a= t >> | tools.ietf.org. >> | | >>> >> | | >>> The IETF Secretariat >> | | >>> >> | | >>> >> | | >>> >> | | >>> _______________________________________________ >> | | >>> 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 >> | | >> >> | | >> >> | | > >> | | > >> | | >> | | >> | | >> |=20 >> |=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 >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From shraddha@juniper.net Mon Oct 21 12:52:35 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9054C11E8263 for ; Mon, 21 Oct 2013 12:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBlFahF9wruI for ; Mon, 21 Oct 2013 12:52:30 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 16D5221F84F9 for ; Mon, 21 Oct 2013 12:50:05 -0700 (PDT) Received: from mail107-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 19:49:56 +0000 Received: from mail107-am1 (localhost [127.0.0.1]) by mail107-am1-R.bigfish.com (Postfix) with ESMTP id 8D85E10014E; Mon, 21 Oct 2013 19:49:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI9371I936eI1454I146fIc430I542I1432I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail107-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shraddha@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(52044002)(51704005)(53754006)(377424004)(199002)(189002)(377454003)(164054003)(52314003)(502244003)(24454002)(85306002)(81542001)(74706001)(66066001)(74876001)(80022001)(65816001)(81342001)(74366001)(63696002)(69226001)(81816001)(81686001)(59766001)(77982001)(76482001)(83072001)(4396001)(19580405001)(83322001)(33646001)(19580395003)(80976001)(54316002)(56776001)(31966008)(74662001)(74502001)(47446002)(47736001)(47976001)(50986001)(49866001)(74316001)(76786001)(15975445006)(76796001)(53806001)(15202345003)(46102001)(76576001)(51856001)(79102001)(54356001)(56816003)(77096001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB127.namprd05.prod.outlook.com; CLIP:116.197.178.83; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail107-am1 (localhost.localdomain [127.0.0.1]) by mail107-am1 (MessageSwitch) id 138238499523516_610; Mon, 21 Oct 2013 19:49:55 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.235]) by mail107-am1.bigfish.com (Postfix) with ESMTP id 0206E380041; Mon, 21 Oct 2013 19:49:55 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 19:49:50 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 21 Oct 2013 19:49:39 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 21 Oct 2013 19:49:37 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.230]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.8.230]) with mapi id 15.00.0785.001; Mon, 21 Oct 2013 19:49:36 +0000 From: Shraddha Hegde To: Acee Lindem Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzpMDx5lxv/i7nUS1brjwnOUyb5n/ju3Q Date: Mon, 21 Oct 2013 19:49:36 +0000 Message-ID: References: <20131021105352.29409.44644.idtracker@ietfa.amsl.com> <0cda3481d5ba41afaf0c61a5bc434b40@BY2PR05MB127.namprd05.prod.outlook.com> <94A203EA12AECE4BA92D42DBFFE0AE470309FF23@eusaamb101.ericsson.se> <75E8F047-BCC2-44AA-8EAC-B9C70226A308@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A00A0@eusaamb101.ericsson.se> <20131021135153.GA7872@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A027F@eusaamb101.ericsson.se> <20131021150847.GA7980@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A1B71@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A1B71@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.83] x-forefront-prvs: 00064751B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 19:52:35 -0000 The "Applicability" section of the draft talks about why RI LSA is chosen a= s the node-tag TLV carrier instead of TE LSA. The point I am trying make here is, if the link-color is carried in a TLV, Node color could also be carried in TLV and we don't need a new LSA for tha= t. Rgds Shraddha -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Tuesday, October 22, 2013 12:53 AM To: Shraddha Hegde Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegd= e-ospf-node-admin-tag-00.txt On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: > Actually, I think separate LSAs is a better alternative. >=20 > Node-tag is a just another property of the node. OSPFv2/v3=20 > have achieved the desired functionality using numerous link/node properti= es using TLVs in TE-LSA so I don't see an absolute necessity of going with = a new LSA. Shraddha - If you think the Router-Information LSA is the same as the TE LS= A you have not read RFC 4970.=20 Acee=20 >=20 > Rgds > Shraddha >=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf=20 > Of Acee Lindem > Sent: Monday, October 21, 2013 8:55 PM > To: Hannes Gredler > Cc: OSPF List; Rob Shakir; Harish Raghuveer > Subject: Re: [OSPF] Review Request: New Version Notification for=20 > draft-hegde-ospf-node-admin-tag-00.txt >=20 >=20 > On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: >=20 >> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: >> |=20 >> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: >> |=20 >> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: >> | | Hannes, >> | | >> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: >> | | >> | | > acee, >> | | > >> | | > why should we give an upper boundary on things which >> | | > - might be subject to change and >> | | > - which have a historic track record of being underestimated. >> | | >> | | You don't have to - just request a separate OSPFv2 opaque LSA a= nd >> | IPv6 OSPFv3 LSA from IANA. >> | | Another alternative would be to extend the RI LSA to be multi- >> | instance and relegate the variable length tags to an instance oth= er >> | than instance 0. >> |=20 >> | again the question why i do have to ? >> | i can perfectly fit in single-digit as well as a few dozens of co= lors >> | in a single RI LSA >> | - what is your concern - except that we may use inappropriate lar= ge >> | space for TE ? >> | any reasonable implementation SHOULD restrict the node color set, >> | such >> | that overwhelming the 64K of RI LSPs is not going to happen. >> |=20 >> | We don't want a standard that leaves room for=20 >> | "unreasonable" implementations ;^). I think the policy in=20 >> | RFC 4970 is clear. Here is an >> | excerpt: >>=20 >> oh boy - i wish i could let the non-sense disappear just with good=20 >> standard docs ;-) - but i hear you - so all you're asking for is an=20 >> upper boundary ? - is 128 low enough to not scare you and be=20 >> compliant to the below paragraph. >=20 > Actually, I think separate LSAs is a better alternative.=20 >=20 >=20 >=20 >>=20 >> | 3. Router Information LSA Opaque Usage and Applicability >> |=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. The intent is to both limit the size of the RI LSA to >> | the point where an OSPF router will always be able to contain the >> | TLVs in a single LSA and to keep the task of determining what has >> | changed between LSA instances reasonably simple. Hence, discretion >> | and sound engineering judgment will need to be applied when decidin= g >> | whether newly proposed TLV(s) in support of a new application are >> | advertised in the RI LSA or warrant the creation of an application >> | specific LSA. >> |=20 >> |=20 >> | Anyway, this hasn't even been presented or accepted as a WG document.= =20 >>=20 >> which is not a reason why we should not discuss how to iron out the bump= y parts now. >=20 > Right. >=20 > Thanks, > Acee >=20 >=20 >>=20 >> thanks ! >>=20 >> /hannes >>=20 >> | | > the 'per-link' admin-groups serve as a good example here: >> | | > initially conceived as "you won't ever need more than >> | 32" we have >> | | > now arrived at a variable length (unbounded) extension. >> | | > >> | | > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- >> | groups-00 >> | | > >> | | > for a humorous take to it, have a look at >> | | > http://tools.ietf.org/html/rfc1925 >> | | > rule (9) and (10) >> | | > >> | | > /hannes >> | | > >> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: >> | | > >> | | >> Hi Shraddha, >> | | >> Since the size of the tag data is unbounded, could you eithe= r >> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit th= e >> | size to some maximum number of tags, e.g., 16? =20 >> | | >> Thanks, >> | | >> Acee >> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >> | | >> >> | | >>> Hi All, >> | | >>> >> | | >>> We have posted a draft on " Advertising per-node >> | administrative tags in OSPF" and would like to hear your vie= ws >> | on it. Please feel free to raise any suggestion/comment on the >> | content. >> | | >>> >> | | >>> Rgds >> | | >>> Shraddha >> | | >>> >> | | >>> -----Original Message----- >> | | >>> From: internet-drafts@ietf.org [mailto:internet- >> | drafts@ietf.org] >> | | >>> Sent: Monday, October 21, 2013 4:24 PM >> | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hann= es >> | Gredler; Rob Shakir >> | | >>> Subject: New Version Notification for draft-hegde-ospf-node= - >> | admin-tag-00.txt >> | | >>> >> | | >>> >> | | >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.tx= t >> | | >>> has been successfully submitted by Shraddha Hegde and poste= d to >> | the IETF repository. >> | | >>> >> | | >>> Filename: draft-hegde-ospf-node-admin-tag >> | | >>> Revision: 00 >> | | >>> Title: Advertising per-node administrative tags in OSPF >> | | >>> Creation date: 2013-10-21 >> | | >>> Group: Individual Submission >> | | >>> Number of pages: 6 >> | | >>> URL: http://www.ietf.org/internet-drafts/draft- >> | hegde-ospf-node-admin-tag-00.txt >> | | >>> Status: http://datatracker.ietf.org/doc/draft-hegd= e- >> | ospf-node-admin-tag >> | | >>> Htmlized: http://tools.ietf.org/html/draft-hegde-osp= f- >> | node-admin-tag-00 >> | | >>> >> | | >>> >> | | >>> Abstract: >> | | >>> This document describes an extension to OSPF protocol [RFC2= 328] >> | to >> | | >>> add an optional operational capability, that allows tagging= and >> | | >>> grouping of the nodes in an OSPF domain. This allows >> | | >>> simplification,ease of management and control over route an= d >> | path >> | | >>> selection based on configured policies. >> | | >>> >> | | >>> This document describes the protocol extensions to dissemin= ate >> | per- >> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. >> | | >>> >> | | >>> >> | | >>> >> | | >>> >> | | >>> >> | | >>> Please note that it may take a couple of minutes from the t= ime >> | of submission until the htmlized version and diff are available a= t >> | tools.ietf.org. >> | | >>> >> | | >>> The IETF Secretariat >> | | >>> >> | | >>> >> | | >>> >> | | >>> _______________________________________________ >> | | >>> 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 >> | | >> >> | | >> >> | | > >> | | > >> | | >> | | >> | | >> |=20 >> |=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 >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Mon Oct 21 12:57:24 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D13E11E86C9 for ; Mon, 21 Oct 2013 12:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9RSPi0AxOfa for ; Mon, 21 Oct 2013 12:57:18 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6944311E81F8 for ; Mon, 21 Oct 2013 12:55:50 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-85-526586c3d098 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7B.AD.03458.3C685625; Mon, 21 Oct 2013 21:55:48 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 15:55:47 -0400 From: Acee Lindem To: Shraddha Hegde Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzpeJzDT6ZhHmikK259DG9ZYkDw== Date: Mon, 21 Oct 2013 19:55:46 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A1CA2@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F2F6AF24E7D784287D3AFFAA3A8D525@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLrHT/dIW2qQwepyi2m3prNZ9N97wmbR fGkzu0XLvXvsFnverWW0uPFoL7MDm0fbl8lMHkuW/GTyuN50ld3jw6ILrAEsUVw2Kak5mWWp Rfp2CVwZkxsbGAt++FWcOXOHuYFxvVUXIyeHhICJxMPmPhYIW0ziwr31bF2MXBxCAkcZJX51 n2aFcJYzSsy7vpcRpIpNQEfi+aN/zCC2iICmxLWJT8GKmAU2MUr07Oth6mLk4BAWyJT4f90P xBQRyJJoX2sCUa4nMWfbZCYQm0VAVWLZjCdgi3kFfCX23VkBZnMKhElsXHuWFcRmBDro+6k1 YPXMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx//A6kWB5nfPWs4KEVeWWPJkPwtEr47Egt2f2CBs a4mPz7ezQtjaEssWvmaGuEFQ4uTMJywTGMVnIVk3C0n7LCTts5C0z0LSvoCRdRUjR2lxallu upHhJkZgPB6TYHPcwbjgk+UhRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MBbHfm9kmMaTbGWRmSS5u1/MfCr7423XFOZ9YDO0qrn5d9cTp+cXrik9T9OYJ5ircXzCUYtp p06f4FAy+L/eqELJfll60kH2zyZ/JzTPf/fWSl5NbZpDxrR5Rb88brJ+/yGYffDyb5vpH+d5 LJm+QFW6KrZfqfTPnJcMd4S1BR5sDM9eWDlTpUOJpTgj0VCLuag4EQDuMJoulQIAAA== Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 19:57:24 -0000 I think we are in a circular argument here and I'm not discuss this independently with each of the authors. Either you have to limit the number of tags, define a new LSA, or do the work to make RI LSA multi-instance. All are viable alternatives with differing pros and cons - including it in the existing RI LSA is not a viable alternative. Remember to request a session if you plan to present it at IETF 88. Thanks, Acee=20 On 10/21/13 12:49 PM, "Shraddha Hegde" wrote: >The "Applicability" section of the draft talks about why RI LSA is chosen >as the node-tag TLV carrier instead of TE LSA. > >The point I am trying make here is, if the link-color is carried in a TLV, >Node color could also be carried in TLV and we don't need a new LSA for >that. > >Rgds >Shraddha > >-----Original Message----- >From: Acee Lindem [mailto:acee.lindem@ericsson.com] >Sent: Tuesday, October 22, 2013 12:53 AM >To: Shraddha Hegde >Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish Raghuveer >Subject: Re: [OSPF] Review Request: New Version Notification for >draft-hegde-ospf-node-admin-tag-00.txt > > >On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: > >> Actually, I think separate LSAs is a better alternative. >>=20 >> Node-tag is a just another property of the node. OSPFv2/v3 >> have achieved the desired functionality using numerous link/node >>properties using TLVs in TE-LSA so I don't see an absolute necessity of >>going with a new LSA. > >Shraddha - If you think the Router-Information LSA is the same as the TE >LSA you have not read RFC 4970. > >Acee=20 > > >>=20 >> Rgds >> Shraddha >>=20 >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf >> Of Acee Lindem >> Sent: Monday, October 21, 2013 8:55 PM >> To: Hannes Gredler >> Cc: OSPF List; Rob Shakir; Harish Raghuveer >> Subject: Re: [OSPF] Review Request: New Version Notification for >> draft-hegde-ospf-node-admin-tag-00.txt >>=20 >>=20 >> On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: >>=20 >>> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: >>> |=20 >>> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: >>> |=20 >>> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: >>> | | Hannes, >>> | | >>> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: >>> | | >>> | | > acee, >>> | | > >>> | | > why should we give an upper boundary on things which >>> | | > - might be subject to change and >>> | | > - which have a historic track record of being >>>underestimated. >>> | | >>> | | You don't have to - just request a separate OSPFv2 opaque LSA >>>and >>> | IPv6 OSPFv3 LSA from IANA. >>> | | Another alternative would be to extend the RI LSA to be multi- >>> | instance and relegate the variable length tags to an instance >>>other >>> | than instance 0. >>> |=20 >>> | again the question why i do have to ? >>> | i can perfectly fit in single-digit as well as a few dozens of >>>colors >>> | in a single RI LSA >>> | - what is your concern - except that we may use inappropriate >>>large >>> | space for TE ? >>> | any reasonable implementation SHOULD restrict the node color >>>set, >>> | such >>> | that overwhelming the 64K of RI LSPs is not going to happen. >>> |=20 >>> | We don't want a standard that leaves room for >>> | "unreasonable" implementations ;^). I think the policy in >>> | RFC 4970 is clear. Here is an >>> | excerpt: >>>=20 >>> oh boy - i wish i could let the non-sense disappear just with good >>> standard docs ;-) - but i hear you - so all you're asking for is an >>> upper boundary ? - is 128 low enough to not scare you and be >>> compliant to the below paragraph. >>=20 >> Actually, I think separate LSAs is a better alternative. >>=20 >>=20 >>=20 >>>=20 >>> | 3. Router Information LSA Opaque Usage and Applicability >>> |=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. The intent is to both limit the size of the RI LSA >>>to >>> | the point where an OSPF router will always be able to contain the >>> | TLVs in a single LSA and to keep the task of determining what has >>> | changed between LSA instances reasonably simple. Hence, >>>discretion >>> | and sound engineering judgment will need to be applied when >>>deciding >>> | whether newly proposed TLV(s) in support of a new application are >>> | advertised in the RI LSA or warrant the creation of an application >>> | specific LSA. >>> |=20 >>> |=20 >>> | Anyway, this hasn't even been presented or accepted as a WG >>>document.=20 >>>=20 >>> which is not a reason why we should not discuss how to iron out the >>>bumpy parts now. >>=20 >> Right. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>>=20 >>> thanks ! >>>=20 >>> /hannes >>>=20 >>> | | > the 'per-link' admin-groups serve as a good example here: >>> | | > initially conceived as "you won't ever need more than >>> | 32" we have >>> | | > now arrived at a variable length (unbounded) extension. >>> | | > >>> | | >=20 >>>http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- >>> | groups-00 >>> | | > >>> | | > for a humorous take to it, have a look at >>> | | > http://tools.ietf.org/html/rfc1925 >>> | | > rule (9) and (10) >>> | | > >>> | | > /hannes >>> | | > >>> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: >>> | | > >>> | | >> Hi Shraddha, >>> | | >> Since the size of the tag data is unbounded, could you >>>either >>> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit >>>the >>> | size to some maximum number of tags, e.g., 16? >>> | | >> Thanks, >>> | | >> Acee >>> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >>> | | >> >>> | | >>> Hi All, >>> | | >>> >>> | | >>> We have posted a draft on " Advertising per-node >>> | administrative tags in OSPF" and would like to hear your >>>views >>> | on it. Please feel free to raise any suggestion/comment on the >>> | content. >>> | | >>> >>> | | >>> Rgds >>> | | >>> Shraddha >>> | | >>> >>> | | >>> -----Original Message----- >>> | | >>> From: internet-drafts@ietf.org [mailto:internet- >>> | drafts@ietf.org] >>> | | >>> Sent: Monday, October 21, 2013 4:24 PM >>> | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; >>>Hannes >>> | Gredler; Rob Shakir >>> | | >>> Subject: New Version Notification for >>>draft-hegde-ospf-node- >>> | admin-tag-00.txt >>> | | >>> >>> | | >>> >>> | | >>> A new version of I-D, >>>draft-hegde-ospf-node-admin-tag-00.txt >>> | | >>> has been successfully submitted by Shraddha Hegde and >>>posted to >>> | the IETF repository. >>> | | >>> >>> | | >>> Filename: draft-hegde-ospf-node-admin-tag >>> | | >>> Revision: 00 >>> | | >>> Title: Advertising per-node administrative tags in OSPF >>> | | >>> Creation date: 2013-10-21 >>> | | >>> Group: Individual Submission >>> | | >>> Number of pages: 6 >>> | | >>> URL: >>>http://www.ietf.org/internet-drafts/draft- >>> | hegde-ospf-node-admin-tag-00.txt >>> | | >>> Status: >>>http://datatracker.ietf.org/doc/draft-hegde- >>> | ospf-node-admin-tag >>> | | >>> Htmlized: >>>http://tools.ietf.org/html/draft-hegde-ospf- >>> | node-admin-tag-00 >>> | | >>> >>> | | >>> >>> | | >>> Abstract: >>> | | >>> This document describes an extension to OSPF protocol >>>[RFC2328] >>> | to >>> | | >>> add an optional operational capability, that allows >>>tagging and >>> | | >>> grouping of the nodes in an OSPF domain. This allows >>> | | >>> simplification,ease of management and control over route >>>and >>> | path >>> | | >>> selection based on configured policies. >>> | | >>> >>> | | >>> This document describes the protocol extensions to >>>disseminate >>> | per- >>> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. >>> | | >>> >>> | | >>> >>> | | >>> >>> | | >>> >>> | | >>> >>> | | >>> 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 >>> | | >>> >>> | | >>> >>> | | >>> >>> | | >>> _______________________________________________ >>> | | >>> 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 >>> | | >> >>> | | >> >>> | | > >>> | | > >>> | | >>> | | >>> | | >>> |=20 >>> |=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 >>=20 >>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > > > From acee.lindem@ericsson.com Tue Oct 22 06:18:21 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9F811E8490 for ; Tue, 22 Oct 2013 06:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ikmpN0GTA+W for ; Tue, 22 Oct 2013 06:18:15 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6F11E8392 for ; Tue, 22 Oct 2013 06:18:15 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-31-52667b154c8d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 41.E3.03458.61B76625; Tue, 22 Oct 2013 15:18:14 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 09:18:13 -0400 From: Acee Lindem To: OSPF List Thread-Topic: Preliminary WG Agenda Thread-Index: AQHOzykp4lZeZmZkGEecnHe6RTpXsg== Date: Tue, 22 Oct 2013 13:18:13 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A3371@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <978E930E5736FC48B3610E6DED6AC592@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXRPgq5YdVqQwY7JGhYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+CmPUwFMxgrrhxcytrAWNXFyMkhIWAicWz1QxYIW0ziwr31 bF2MXBxCAkcZJbYff80E4SxnlNj1axErSBWbgI7E80f/mEFsEQFZiaVL9oPFhQXkJT6+7GCH iKtI9M7eBWXrSexb9wDMZhFQlZgy5whYPa+Ar8S+l5sYQWxGoM3fT61hArGZBcQlbj2ZzwRx kYDEkj3nmSFsUYmXj/+xQtjKEkue7GeBqNeRWLD7ExuEbS3R8/4JVFxbYtnC18wQuwQlTs58 wjKBUWQWkhWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxluYgQG/jEJNscdjAs+WR5ilOZg URLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY4H5Wr+NtywTM2abXv+8Zd2lGbbB WZt7OWPnbrfYc09gTvtC1Qy7hNzJCV6GantfFJ6TMLc6eI5L8KqWzVn+E0o8PTGrVnvFZ+y7 slYobg+PrdGhE/HJLLG2iq5/Wu0XPnj8hjHlO+eEVWoFwnGaDnW3T1RPEGv7KHL30XXhiIjH gtrX7zjeV2Ipzkg01GIuKk4EAKxIHc5KAgAA Subject: [OSPF] Preliminary WG Agenda X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 13:18:22 -0000 Abhay and I are putting together the preliminary agenda. We have a lot of r= equests this IETF but hopefully everything will fit.=20 Thanks, Acee = From asmirnov@cisco.com Tue Oct 22 12:50:09 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D436411E821A for ; Tue, 22 Oct 2013 12:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7emFELDQv57I for ; Tue, 22 Oct 2013 12:50:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB38521F9E5A for ; Tue, 22 Oct 2013 12:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11022; q=dns/txt; s=iport; t=1382471321; x=1383680921; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Uw1kUow2SQivhNXutH230eBFECi4aP98nWXMFDq1blI=; b=Gq207C2+kfjjUNWhMnnrBITpnJljKJPAriMKaVK745/fHNm17M6beuWt qny69P0RCY/w3/cYK29B/0g37fUavUZXYXIFqRChOnx87OQ/17e1uVmat owoIdlwqCjQjp8Zes1noAESGMx7WIlkBOsCmmgN9mP4nTm0H5haTlz2A3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAEbWZlKQ/khM/2dsb2JhbABZgwc4vx6BKxZ0giUBAQEEAQEBNS8HCQIMBAsRBAEBAQkeBw8CFh8JCAYBDAEFAgEBBYd9DbsKjhCBPgcGhCMDmAmBL5BYgWaBQDqBLQ X-IronPort-AV: E=Sophos;i="4.93,550,1378857600"; d="scan'208";a="160914919" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2013 19:48:39 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9MJmX3O027433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 19:48:36 GMT Message-ID: <5266D691.703@cisco.com> Date: Tue, 22 Oct 2013 21:48:33 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Acee Lindem , Shraddha Hegde References: <94A203EA12AECE4BA92D42DBFFE0AE47030A1CA2@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A1CA2@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 19:50:10 -0000 Hi Acee, it looks to me that the most probable deployment will use 1 tag. Router advertising 100 tags already sounds unreasonable. Defining new LSID to originate LSA with (typically) only 4 bytes of useful information is not optimal. Choice of RI LSA to advertise some small data is reasonable. RI LSA is far from getting too big. If there is a concern of RI LSA overfilling then we can extend range of opaque IDs - but is it really necessary at this point? Anton On 10/21/2013 09:55 PM, Acee Lindem wrote: > I think we are in a circular argument here and I'm not discuss this > independently with each of the authors. Either you have to limit the > number of tags, define a new LSA, or do the work to make RI LSA > multi-instance. All are viable alternatives with differing pros and cons - > including it in the existing RI LSA is not a viable alternative. Remember > to request a session if you plan to present it at IETF 88. > Thanks, > Acee > > On 10/21/13 12:49 PM, "Shraddha Hegde" wrote: > >> The "Applicability" section of the draft talks about why RI LSA is chosen >> as the node-tag TLV carrier instead of TE LSA. >> >> The point I am trying make here is, if the link-color is carried in a TLV, >> Node color could also be carried in TLV and we don't need a new LSA for >> that. >> >> Rgds >> Shraddha >> >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Tuesday, October 22, 2013 12:53 AM >> To: Shraddha Hegde >> Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish Raghuveer >> Subject: Re: [OSPF] Review Request: New Version Notification for >> draft-hegde-ospf-node-admin-tag-00.txt >> >> >> On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: >> >>> Actually, I think separate LSAs is a better alternative. >>> >>> Node-tag is a just another property of the node. OSPFv2/v3 >>> have achieved the desired functionality using numerous link/node >>> properties using TLVs in TE-LSA so I don't see an absolute necessity of >>> going with a new LSA. >> >> Shraddha - If you think the Router-Information LSA is the same as the TE >> LSA you have not read RFC 4970. >> >> Acee >> >> >>> >>> Rgds >>> Shraddha >>> >>> -----Original Message----- >>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf >>> Of Acee Lindem >>> Sent: Monday, October 21, 2013 8:55 PM >>> To: Hannes Gredler >>> Cc: OSPF List; Rob Shakir; Harish Raghuveer >>> Subject: Re: [OSPF] Review Request: New Version Notification for >>> draft-hegde-ospf-node-admin-tag-00.txt >>> >>> >>> On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: >>> >>>> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: >>>> | >>>> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: >>>> | >>>> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: >>>> | | Hannes, >>>> | | >>>> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: >>>> | | >>>> | | > acee, >>>> | | > >>>> | | > why should we give an upper boundary on things which >>>> | | > - might be subject to change and >>>> | | > - which have a historic track record of being >>>> underestimated. >>>> | | >>>> | | You don't have to - just request a separate OSPFv2 opaque LSA >>>> and >>>> | IPv6 OSPFv3 LSA from IANA. >>>> | | Another alternative would be to extend the RI LSA to be multi- >>>> | instance and relegate the variable length tags to an instance >>>> other >>>> | than instance 0. >>>> | >>>> | again the question why i do have to ? >>>> | i can perfectly fit in single-digit as well as a few dozens of >>>> colors >>>> | in a single RI LSA >>>> | - what is your concern - except that we may use inappropriate >>>> large >>>> | space for TE ? >>>> | any reasonable implementation SHOULD restrict the node color >>>> set, >>>> | such >>>> | that overwhelming the 64K of RI LSPs is not going to happen. >>>> | >>>> | We don't want a standard that leaves room for >>>> | "unreasonable" implementations ;^). I think the policy in >>>> | RFC 4970 is clear. Here is an >>>> | excerpt: >>>> >>>> oh boy - i wish i could let the non-sense disappear just with good >>>> standard docs ;-) - but i hear you - so all you're asking for is an >>>> upper boundary ? - is 128 low enough to not scare you and be >>>> compliant to the below paragraph. >>> >>> Actually, I think separate LSAs is a better alternative. >>> >>> >>> >>>> >>>> | 3. Router Information LSA Opaque Usage and Applicability >>>> | >>>> | 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. The intent is to both limit the size of the RI LSA >>>> to >>>> | the point where an OSPF router will always be able to contain the >>>> | TLVs in a single LSA and to keep the task of determining what has >>>> | changed between LSA instances reasonably simple. Hence, >>>> discretion >>>> | and sound engineering judgment will need to be applied when >>>> deciding >>>> | whether newly proposed TLV(s) in support of a new application are >>>> | advertised in the RI LSA or warrant the creation of an application >>>> | specific LSA. >>>> | >>>> | >>>> | Anyway, this hasn't even been presented or accepted as a WG >>>> document. >>>> >>>> which is not a reason why we should not discuss how to iron out the >>>> bumpy parts now. >>> >>> Right. >>> >>> Thanks, >>> Acee >>> >>> >>>> >>>> thanks ! >>>> >>>> /hannes >>>> >>>> | | > the 'per-link' admin-groups serve as a good example here: >>>> | | > initially conceived as "you won't ever need more than >>>> | 32" we have >>>> | | > now arrived at a variable length (unbounded) extension. >>>> | | > >>>> | | > >>>> http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- >>>> | groups-00 >>>> | | > >>>> | | > for a humorous take to it, have a look at >>>> | | > http://tools.ietf.org/html/rfc1925 >>>> | | > rule (9) and (10) >>>> | | > >>>> | | > /hannes >>>> | | > >>>> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: >>>> | | > >>>> | | >> Hi Shraddha, >>>> | | >> Since the size of the tag data is unbounded, could you >>>> either >>>> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit >>>> the >>>> | size to some maximum number of tags, e.g., 16? >>>> | | >> Thanks, >>>> | | >> Acee >>>> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >>>> | | >> >>>> | | >>> Hi All, >>>> | | >>> >>>> | | >>> We have posted a draft on " Advertising per-node >>>> | administrative tags in OSPF" and would like to hear your >>>> views >>>> | on it. Please feel free to raise any suggestion/comment on the >>>> | content. >>>> | | >>> >>>> | | >>> Rgds >>>> | | >>> Shraddha >>>> | | >>> >>>> | | >>> -----Original Message----- >>>> | | >>> From: internet-drafts@ietf.org [mailto:internet- >>>> | drafts@ietf.org] >>>> | | >>> Sent: Monday, October 21, 2013 4:24 PM >>>> | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; >>>> Hannes >>>> | Gredler; Rob Shakir >>>> | | >>> Subject: New Version Notification for >>>> draft-hegde-ospf-node- >>>> | admin-tag-00.txt >>>> | | >>> >>>> | | >>> >>>> | | >>> A new version of I-D, >>>> draft-hegde-ospf-node-admin-tag-00.txt >>>> | | >>> has been successfully submitted by Shraddha Hegde and >>>> posted to >>>> | the IETF repository. >>>> | | >>> >>>> | | >>> Filename: draft-hegde-ospf-node-admin-tag >>>> | | >>> Revision: 00 >>>> | | >>> Title: Advertising per-node administrative tags in OSPF >>>> | | >>> Creation date: 2013-10-21 >>>> | | >>> Group: Individual Submission >>>> | | >>> Number of pages: 6 >>>> | | >>> URL: >>>> http://www.ietf.org/internet-drafts/draft- >>>> | hegde-ospf-node-admin-tag-00.txt >>>> | | >>> Status: >>>> http://datatracker.ietf.org/doc/draft-hegde- >>>> | ospf-node-admin-tag >>>> | | >>> Htmlized: >>>> http://tools.ietf.org/html/draft-hegde-ospf- >>>> | node-admin-tag-00 >>>> | | >>> >>>> | | >>> >>>> | | >>> Abstract: >>>> | | >>> This document describes an extension to OSPF protocol >>>> [RFC2328] >>>> | to >>>> | | >>> add an optional operational capability, that allows >>>> tagging and >>>> | | >>> grouping of the nodes in an OSPF domain. This allows >>>> | | >>> simplification,ease of management and control over route >>>> and >>>> | path >>>> | | >>> selection based on configured policies. >>>> | | >>> >>>> | | >>> This document describes the protocol extensions to >>>> disseminate >>>> | per- >>>> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. >>>> | | >>> >>>> | | >>> >>>> | | >>> >>>> | | >>> >>>> | | >>> >>>> | | >>> 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 >>>> | | >>> >>>> | | >>> >>>> | | >>> >>>> | | >>> _______________________________________________ >>>> | | >>> 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 >>> >>> _______________________________________________ >>> 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 acee.lindem@ericsson.com Tue Oct 22 13:05:30 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E306411E8222 for ; Tue, 22 Oct 2013 13:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAp1AQubNWSL for ; Tue, 22 Oct 2013 13:05:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58511E823D for ; Tue, 22 Oct 2013 13:05:22 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-1e-5266da791440 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E5.AE.03458.97AD6625; Tue, 22 Oct 2013 22:05:14 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 16:05:09 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzpeJzDT6ZhHmikK259DG9ZYkD5oBZUCAgAAEogA= Date: Tue, 22 Oct 2013 20:05:09 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A3CE3@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE47030A1CA2@eusaamb101.ericsson.se> <5266D691.703@cisco.com> In-Reply-To: <5266D691.703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPoG7VrbQggx0HuC1atrFaNF/azG7R cu8eu8Wed2sZLW482svswOrR9mUyk8eU3xtZPZYs+cnkcb3pKnsASxSXTUpqTmZZapG+XQJX Rs/uC2wFP2Mrpr66zNLAeMeti5GTQ0LARGLp7V2sELaYxIV769m6GLk4hASOMko0fuljhnCW M0qc3nYKrIpNQEfi+aN/zCC2iICaxOa7n1hBipgFJjNKzLnymr2LkYNDWCBT4v91PxBTRCBL on2tCUS5lUTrz2csIDaLgKrE73932EFsXgFfiWlHzoKNFBLIkJjdPJ8RxOYEqll9/ClYnBHo uO+n1jCB2MwC4hK3nsxngjhaQGLJnvPMELaoxMvH/6CeUZZY8mQ/C0S9jsSC3Z/YIGxriY// bjJD2NoSyxa+Zoa4QVDi5MwnLBMYxWchWTELSfssJO2zkLTPQtK+gJF1FSNHaXFqWW66keEm RmAUHpNgc9zBuOCT5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwerju XPKP9dW2nQp/pZJWzZTmczL+VMh3dCPDu7zO+Dlbk31ORYhuv2e95GXlmX25HT99b0bNTHny 8aPaZk0NnTUy35JLVeOmnvi14qjVjegfPh4/3n/db3RN1nz2/x02Z1bE6JVEHwnXqOiqmrlQ L8Pkt+lhU9XkJW9zUhctmSkW/fHqdWbr5UosxRmJhlrMRcWJANSlixKQAgAA Cc: OSPF List , Harish Raghuveer , Rob Shakir Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 20:05:31 -0000 I don't disagree that the typical use case is a single tag with the likelih= ood of mult-tag use cases diminishing exponentially as the number of tags i= ncreases. My point is that unbounded TLVs MUST NOT be included in the OSPF = RI LSA. What part of that is hard to understand?=20 I think that 16 is a reasonable maximum and that beyond 16 would imply enco= ding ulterior information that should have its own TLV or LSA anyway.=20 Acee=20 On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote: > Hi Acee, > it looks to me that the most probable deployment will use 1 tag. Router= advertising 100 tags already sounds unreasonable. > Defining new LSID to originate LSA with (typically) only 4 bytes of use= ful information is not optimal. Choice of RI LSA to advertise some small da= ta is reasonable. > RI LSA is far from getting too big. If there is a concern of RI LSA ove= rfilling then we can extend range of opaque IDs - but is it really necessar= y at this point? >=20 > Anton >=20 >=20 > On 10/21/2013 09:55 PM, Acee Lindem wrote: >> I think we are in a circular argument here and I'm not discuss this >> independently with each of the authors. Either you have to limit the >> number of tags, define a new LSA, or do the work to make RI LSA >> multi-instance. All are viable alternatives with differing pros and cons= - >> including it in the existing RI LSA is not a viable alternative. Remembe= r >> to request a session if you plan to present it at IETF 88. >> Thanks, >> Acee >>=20 >> On 10/21/13 12:49 PM, "Shraddha Hegde" wrote: >>=20 >>> The "Applicability" section of the draft talks about why RI LSA is chos= en >>> as the node-tag TLV carrier instead of TE LSA. >>>=20 >>> The point I am trying make here is, if the link-color is carried in a T= LV, >>> Node color could also be carried in TLV and we don't need a new LSA for >>> that. >>>=20 >>> Rgds >>> Shraddha >>>=20 >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: Tuesday, October 22, 2013 12:53 AM >>> To: Shraddha Hegde >>> Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish Raghuvee= r >>> Subject: Re: [OSPF] Review Request: New Version Notification for >>> draft-hegde-ospf-node-admin-tag-00.txt >>>=20 >>>=20 >>> On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: >>>=20 >>>> Actually, I think separate LSAs is a better alternative. >>>>=20 >>>> Node-tag is a just another property of the node. OSPFv2/v3 >>>> have achieved the desired functionality using numerous link/node >>>> properties using TLVs in TE-LSA so I don't see an absolute necessity o= f >>>> going with a new LSA. >>>=20 >>> Shraddha - If you think the Router-Information LSA is the same as the T= E >>> LSA you have not read RFC 4970. >>>=20 >>> Acee >>>=20 >>>=20 >>>>=20 >>>> Rgds >>>> Shraddha >>>>=20 >>>> -----Original Message----- >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf >>>> Of Acee Lindem >>>> Sent: Monday, October 21, 2013 8:55 PM >>>> To: Hannes Gredler >>>> Cc: OSPF List; Rob Shakir; Harish Raghuveer >>>> Subject: Re: [OSPF] Review Request: New Version Notification for >>>> draft-hegde-ospf-node-admin-tag-00.txt >>>>=20 >>>>=20 >>>> On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: >>>>=20 >>>>> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: >>>>> | >>>>> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: >>>>> | >>>>> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: >>>>> | | Hannes, >>>>> | | >>>>> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: >>>>> | | >>>>> | | > acee, >>>>> | | > >>>>> | | > why should we give an upper boundary on things which >>>>> | | > - might be subject to change and >>>>> | | > - which have a historic track record of being >>>>> underestimated. >>>>> | | >>>>> | | You don't have to - just request a separate OSPFv2 opaque LS= A >>>>> and >>>>> | IPv6 OSPFv3 LSA from IANA. >>>>> | | Another alternative would be to extend the RI LSA to be mult= i- >>>>> | instance and relegate the variable length tags to an instance >>>>> other >>>>> | than instance 0. >>>>> | >>>>> | again the question why i do have to ? >>>>> | i can perfectly fit in single-digit as well as a few dozens of >>>>> colors >>>>> | in a single RI LSA >>>>> | - what is your concern - except that we may use inappropriate >>>>> large >>>>> | space for TE ? >>>>> | any reasonable implementation SHOULD restrict the node color >>>>> set, >>>>> | such >>>>> | that overwhelming the 64K of RI LSPs is not going to happen. >>>>> | >>>>> | We don't want a standard that leaves room for >>>>> | "unreasonable" implementations ;^). I think the policy in >>>>> | RFC 4970 is clear. Here is an >>>>> | excerpt: >>>>>=20 >>>>> oh boy - i wish i could let the non-sense disappear just with good >>>>> standard docs ;-) - but i hear you - so all you're asking for is an >>>>> upper boundary ? - is 128 low enough to not scare you and be >>>>> compliant to the below paragraph. >>>>=20 >>>> Actually, I think separate LSAs is a better alternative. >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> | 3. Router Information LSA Opaque Usage and Applicability >>>>> | >>>>> | The purpose of the Router Information (RI) LSA is to advertise >>>>> | information relating to the aggregate OSPF router. Normally, th= is >>>>> | should be confined to TLVs with a single value or very few value= s. >>>>> | It is not meant to be a generic container to carry any and all >>>>> | information. The intent is to both limit the size of the RI LSA >>>>> to >>>>> | the point where an OSPF router will always be able to contain th= e >>>>> | TLVs in a single LSA and to keep the task of determining what ha= s >>>>> | changed between LSA instances reasonably simple. Hence, >>>>> discretion >>>>> | and sound engineering judgment will need to be applied when >>>>> deciding >>>>> | whether newly proposed TLV(s) in support of a new application ar= e >>>>> | advertised in the RI LSA or warrant the creation of an applicati= on >>>>> | specific LSA. >>>>> | >>>>> | >>>>> | Anyway, this hasn't even been presented or accepted as a WG >>>>> document. >>>>>=20 >>>>> which is not a reason why we should not discuss how to iron out the >>>>> bumpy parts now. >>>>=20 >>>> Right. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=20 >>>>>=20 >>>>> thanks ! >>>>>=20 >>>>> /hannes >>>>>=20 >>>>> | | > the 'per-link' admin-groups serve as a good example here: >>>>> | | > initially conceived as "you won't ever need more than >>>>> | 32" we have >>>>> | | > now arrived at a variable length (unbounded) extension. >>>>> | | > >>>>> | | > >>>>> http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- >>>>> | groups-00 >>>>> | | > >>>>> | | > for a humorous take to it, have a look at >>>>> | | > http://tools.ietf.org/html/rfc1925 >>>>> | | > rule (9) and (10) >>>>> | | > >>>>> | | > /hannes >>>>> | | > >>>>> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: >>>>> | | > >>>>> | | >> Hi Shraddha, >>>>> | | >> Since the size of the tag data is unbounded, could you >>>>> either >>>>> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit >>>>> the >>>>> | size to some maximum number of tags, e.g., 16? >>>>> | | >> Thanks, >>>>> | | >> Acee >>>>> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >>>>> | | >> >>>>> | | >>> Hi All, >>>>> | | >>> >>>>> | | >>> We have posted a draft on " Advertising per-node >>>>> | administrative tags in OSPF" and would like to hear your >>>>> views >>>>> | on it. Please feel free to raise any suggestion/comment on the >>>>> | content. >>>>> | | >>> >>>>> | | >>> Rgds >>>>> | | >>> Shraddha >>>>> | | >>> >>>>> | | >>> -----Original Message----- >>>>> | | >>> From: internet-drafts@ietf.org [mailto:internet- >>>>> | drafts@ietf.org] >>>>> | | >>> Sent: Monday, October 21, 2013 4:24 PM >>>>> | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; >>>>> Hannes >>>>> | Gredler; Rob Shakir >>>>> | | >>> Subject: New Version Notification for >>>>> draft-hegde-ospf-node- >>>>> | admin-tag-00.txt >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> A new version of I-D, >>>>> draft-hegde-ospf-node-admin-tag-00.txt >>>>> | | >>> has been successfully submitted by Shraddha Hegde and >>>>> posted to >>>>> | the IETF repository. >>>>> | | >>> >>>>> | | >>> Filename: draft-hegde-ospf-node-admin-tag >>>>> | | >>> Revision: 00 >>>>> | | >>> Title: Advertising per-node administrative tags in OSPF >>>>> | | >>> Creation date: 2013-10-21 >>>>> | | >>> Group: Individual Submission >>>>> | | >>> Number of pages: 6 >>>>> | | >>> URL: >>>>> http://www.ietf.org/internet-drafts/draft- >>>>> | hegde-ospf-node-admin-tag-00.txt >>>>> | | >>> Status: >>>>> http://datatracker.ietf.org/doc/draft-hegde- >>>>> | ospf-node-admin-tag >>>>> | | >>> Htmlized: >>>>> http://tools.ietf.org/html/draft-hegde-ospf- >>>>> | node-admin-tag-00 >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> Abstract: >>>>> | | >>> This document describes an extension to OSPF protocol >>>>> [RFC2328] >>>>> | to >>>>> | | >>> add an optional operational capability, that allows >>>>> tagging and >>>>> | | >>> grouping of the nodes in an OSPF domain. This allows >>>>> | | >>> simplification,ease of management and control over route >>>>> and >>>>> | path >>>>> | | >>> selection based on configured policies. >>>>> | | >>> >>>>> | | >>> This document describes the protocol extensions to >>>>> disseminate >>>>> | per- >>>>> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> Please note that it may take a couple of minutes from th= e >>>>> time >>>>> | of submission until the htmlized version and diff are availabl= e >>>>> at >>>>> | tools.ietf.org. >>>>> | | >>> >>>>> | | >>> The IETF Secretariat >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> >>>>> | | >>> _______________________________________________ >>>>> | | >>> 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 >>>>> | | >> >>>>> | | >> >>>>> | | > >>>>> | | > >>>>> | | >>>>> | | >>>>> | | >>>>> | >>>>> | >>>>>=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 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 From hannes@juniper.net Wed Oct 23 00:27:48 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DA711E8305 for ; Wed, 23 Oct 2013 00:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SVsNikokN3k for ; Wed, 23 Oct 2013 00:27:42 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0547711E8309 for ; Wed, 23 Oct 2013 00:27:41 -0700 (PDT) Received: from mail146-db9-R.bigfish.com (10.174.16.229) by DB9EHSOBE006.bigfish.com (10.174.14.69) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Oct 2013 07:27:41 +0000 Received: from mail146-db9 (localhost [127.0.0.1]) by mail146-db9-R.bigfish.com (Postfix) with ESMTP id EA36524011E; Wed, 23 Oct 2013 07:27:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dI98dI9371I936eI1454I146fIc430I542I1418I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail146-db9: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail146-db9 (localhost.localdomain [127.0.0.1]) by mail146-db9 (MessageSwitch) id 1382513259389233_30370; Wed, 23 Oct 2013 07:27:39 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.244]) by mail146-db9.bigfish.com (Postfix) with ESMTP id 59B01120071; Wed, 23 Oct 2013 07:27:39 +0000 (UTC) Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Oct 2013 07:27:38 +0000 Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 23 Oct 2013 07:27:34 +0000 Date: Wed, 23 Oct 2013 09:27:27 +0200 From: Hannes Gredler To: Acee Lindem Message-ID: <20131023072727.GA12319@juniper.net> References: <94A203EA12AECE4BA92D42DBFFE0AE47030A1CA2@eusaamb101.ericsson.se> <5266D691.703@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE47030A3CE3@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A3CE3@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 07:27:48 -0000 acee, i think that 16 is an unreasonable max threshold as we have proof point (e.g. link-colors) that even 32 colors are not enough - so support for 64 colors is the bare minimum that SPs are looking for. i fail to see the threat of overfilling the RI, with worst case 400 bytes (100 colors). furthermore it is an upper boundary number ... /hannes On Tue, Oct 22, 2013 at 08:05:09PM +0000, Acee Lindem wrote: | I don't disagree that the typical use case is a single tag with the likelihood of mult-tag use cases diminishing exponentially as the number of tags increases. My point is that unbounded TLVs MUST NOT be included in the OSPF RI LSA. What part of that is hard to understand? | I think that 16 is a reasonable maximum and that beyond 16 would imply encoding ulterior information that should have its own TLV or LSA anyway. | Acee | | On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote: | | > Hi Acee, | > it looks to me that the most probable deployment will use 1 tag. Router advertising 100 tags already sounds unreasonable. | > Defining new LSID to originate LSA with (typically) only 4 bytes of useful information is not optimal. Choice of RI LSA to advertise some small data is reasonable. | > RI LSA is far from getting too big. If there is a concern of RI LSA overfilling then we can extend range of opaque IDs - but is it really necessary at this point? | > | > Anton | > | > | > On 10/21/2013 09:55 PM, Acee Lindem wrote: | >> I think we are in a circular argument here and I'm not discuss this | >> independently with each of the authors. Either you have to limit the | >> number of tags, define a new LSA, or do the work to make RI LSA | >> multi-instance. All are viable alternatives with differing pros and cons - | >> including it in the existing RI LSA is not a viable alternative. Remember | >> to request a session if you plan to present it at IETF 88. | >> Thanks, | >> Acee | >> | >> On 10/21/13 12:49 PM, "Shraddha Hegde" wrote: | >> | >>> The "Applicability" section of the draft talks about why RI LSA is chosen | >>> as the node-tag TLV carrier instead of TE LSA. | >>> | >>> The point I am trying make here is, if the link-color is carried in a TLV, | >>> Node color could also be carried in TLV and we don't need a new LSA for | >>> that. | >>> | >>> Rgds | >>> Shraddha | >>> | >>> -----Original Message----- | >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] | >>> Sent: Tuesday, October 22, 2013 12:53 AM | >>> To: Shraddha Hegde | >>> Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish Raghuveer | >>> Subject: Re: [OSPF] Review Request: New Version Notification for | >>> draft-hegde-ospf-node-admin-tag-00.txt | >>> | >>> | >>> On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: | >>> | >>>> Actually, I think separate LSAs is a better alternative. | >>>> | >>>> Node-tag is a just another property of the node. OSPFv2/v3 | >>>> have achieved the desired functionality using numerous link/node | >>>> properties using TLVs in TE-LSA so I don't see an absolute necessity of | >>>> going with a new LSA. | >>> | >>> Shraddha - If you think the Router-Information LSA is the same as the TE | >>> LSA you have not read RFC 4970. | >>> | >>> Acee | >>> | >>> | >>>> | >>>> Rgds | >>>> Shraddha | >>>> | >>>> -----Original Message----- | >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf | >>>> Of Acee Lindem | >>>> Sent: Monday, October 21, 2013 8:55 PM | >>>> To: Hannes Gredler | >>>> Cc: OSPF List; Rob Shakir; Harish Raghuveer | >>>> Subject: Re: [OSPF] Review Request: New Version Notification for | >>>> draft-hegde-ospf-node-admin-tag-00.txt | >>>> | >>>> | >>>> On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: | >>>> | >>>>> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: | >>>>> | | >>>>> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: | >>>>> | | >>>>> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: | >>>>> | | Hannes, | >>>>> | | | >>>>> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: | >>>>> | | | >>>>> | | > acee, | >>>>> | | > | >>>>> | | > why should we give an upper boundary on things which | >>>>> | | > - might be subject to change and | >>>>> | | > - which have a historic track record of being | >>>>> underestimated. | >>>>> | | | >>>>> | | You don't have to - just request a separate OSPFv2 opaque LSA | >>>>> and | >>>>> | IPv6 OSPFv3 LSA from IANA. | >>>>> | | Another alternative would be to extend the RI LSA to be multi- | >>>>> | instance and relegate the variable length tags to an instance | >>>>> other | >>>>> | than instance 0. | >>>>> | | >>>>> | again the question why i do have to ? | >>>>> | i can perfectly fit in single-digit as well as a few dozens of | >>>>> colors | >>>>> | in a single RI LSA | >>>>> | - what is your concern - except that we may use inappropriate | >>>>> large | >>>>> | space for TE ? | >>>>> | any reasonable implementation SHOULD restrict the node color | >>>>> set, | >>>>> | such | >>>>> | that overwhelming the 64K of RI LSPs is not going to happen. | >>>>> | | >>>>> | We don't want a standard that leaves room for | >>>>> | "unreasonable" implementations ;^). I think the policy in | >>>>> | RFC 4970 is clear. Here is an | >>>>> | excerpt: | >>>>> | >>>>> oh boy - i wish i could let the non-sense disappear just with good | >>>>> standard docs ;-) - but i hear you - so all you're asking for is an | >>>>> upper boundary ? - is 128 low enough to not scare you and be | >>>>> compliant to the below paragraph. | >>>> | >>>> Actually, I think separate LSAs is a better alternative. | >>>> | >>>> | >>>> | >>>>> | >>>>> | 3. Router Information LSA Opaque Usage and Applicability | >>>>> | | >>>>> | 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. The intent is to both limit the size of the RI LSA | >>>>> to | >>>>> | the point where an OSPF router will always be able to contain the | >>>>> | TLVs in a single LSA and to keep the task of determining what has | >>>>> | changed between LSA instances reasonably simple. Hence, | >>>>> discretion | >>>>> | and sound engineering judgment will need to be applied when | >>>>> deciding | >>>>> | whether newly proposed TLV(s) in support of a new application are | >>>>> | advertised in the RI LSA or warrant the creation of an application | >>>>> | specific LSA. | >>>>> | | >>>>> | | >>>>> | Anyway, this hasn't even been presented or accepted as a WG | >>>>> document. | >>>>> | >>>>> which is not a reason why we should not discuss how to iron out the | >>>>> bumpy parts now. | >>>> | >>>> Right. | >>>> | >>>> Thanks, | >>>> Acee | >>>> | >>>> | >>>>> | >>>>> thanks ! | >>>>> | >>>>> /hannes | >>>>> | >>>>> | | > the 'per-link' admin-groups serve as a good example here: | >>>>> | | > initially conceived as "you won't ever need more than | >>>>> | 32" we have | >>>>> | | > now arrived at a variable length (unbounded) extension. | >>>>> | | > | >>>>> | | > | >>>>> http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- | >>>>> | groups-00 | >>>>> | | > | >>>>> | | > for a humorous take to it, have a look at | >>>>> | | > http://tools.ietf.org/html/rfc1925 | >>>>> | | > rule (9) and (10) | >>>>> | | > | >>>>> | | > /hannes | >>>>> | | > | >>>>> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: | >>>>> | | > | >>>>> | | >> Hi Shraddha, | >>>>> | | >> Since the size of the tag data is unbounded, could you | >>>>> either | >>>>> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit | >>>>> the | >>>>> | size to some maximum number of tags, e.g., 16? | >>>>> | | >> Thanks, | >>>>> | | >> Acee | >>>>> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: | >>>>> | | >> | >>>>> | | >>> Hi All, | >>>>> | | >>> | >>>>> | | >>> We have posted a draft on " Advertising per-node | >>>>> | administrative tags in OSPF" and would like to hear your | >>>>> views | >>>>> | on it. Please feel free to raise any suggestion/comment on the | >>>>> | content. | >>>>> | | >>> | >>>>> | | >>> Rgds | >>>>> | | >>> Shraddha | >>>>> | | >>> | >>>>> | | >>> -----Original Message----- | >>>>> | | >>> From: internet-drafts@ietf.org [mailto:internet- | >>>>> | drafts@ietf.org] | >>>>> | | >>> Sent: Monday, October 21, 2013 4:24 PM | >>>>> | | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; | >>>>> Hannes | >>>>> | Gredler; Rob Shakir | >>>>> | | >>> Subject: New Version Notification for | >>>>> draft-hegde-ospf-node- | >>>>> | admin-tag-00.txt | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> A new version of I-D, | >>>>> draft-hegde-ospf-node-admin-tag-00.txt | >>>>> | | >>> has been successfully submitted by Shraddha Hegde and | >>>>> posted to | >>>>> | the IETF repository. | >>>>> | | >>> | >>>>> | | >>> Filename: draft-hegde-ospf-node-admin-tag | >>>>> | | >>> Revision: 00 | >>>>> | | >>> Title: Advertising per-node administrative tags in OSPF | >>>>> | | >>> Creation date: 2013-10-21 | >>>>> | | >>> Group: Individual Submission | >>>>> | | >>> Number of pages: 6 | >>>>> | | >>> URL: | >>>>> http://www.ietf.org/internet-drafts/draft- | >>>>> | hegde-ospf-node-admin-tag-00.txt | >>>>> | | >>> Status: | >>>>> http://datatracker.ietf.org/doc/draft-hegde- | >>>>> | ospf-node-admin-tag | >>>>> | | >>> Htmlized: | >>>>> http://tools.ietf.org/html/draft-hegde-ospf- | >>>>> | node-admin-tag-00 | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> Abstract: | >>>>> | | >>> This document describes an extension to OSPF protocol | >>>>> [RFC2328] | >>>>> | to | >>>>> | | >>> add an optional operational capability, that allows | >>>>> tagging and | >>>>> | | >>> grouping of the nodes in an OSPF domain. This allows | >>>>> | | >>> simplification,ease of management and control over route | >>>>> and | >>>>> | path | >>>>> | | >>> selection based on configured policies. | >>>>> | | >>> | >>>>> | | >>> This document describes the protocol extensions to | >>>>> disseminate | >>>>> | per- | >>>>> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> 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 | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | >>> _______________________________________________ | >>>>> | | >>> 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 | >>>> | >>>> _______________________________________________ | >>>> 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 | >> | | _______________________________________________ | OSPF mailing list | OSPF@ietf.org | https://www.ietf.org/mailman/listinfo/ospf | | From acee.lindem@ericsson.com Wed Oct 23 04:48:22 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B355611E8260 for ; Wed, 23 Oct 2013 04:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWSfHTMs5Sf0 for ; Wed, 23 Oct 2013 04:48:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 15A8711E8197 for ; Wed, 23 Oct 2013 04:48:07 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-61-5267b775f544 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FE.91.03458.677B7625; Wed, 23 Oct 2013 13:48:06 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 07:48:05 -0400 From: Acee Lindem To: Peter Psenak , "Jeffrey (Zhaohui) Zhang" , Huaimo Chen , Lizhenbin , Yangang Thread-Topic: OSPF WG IETF 88 Preliminary Agenda Thread-Index: AQHOz+W8m0oLN8bXLk6DrPaW2l14AQ== Date: Wed, 23 Oct 2013 11:48:05 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A542A@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <6A1D203D4EBB1E4BB963284E4BEBEDE5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPuG7Z9vQgg86NIhZbn15htNjd+Ifd ouXePXaLHbvb2Sx6nlxhtjhysZHFgc1jyu+NrB4tR96yeixZ8pPJ43rTVfYAligum5TUnMyy 1CJ9uwSujCevrzAXLGetWHowu4FxPksXIyeHhICJRO/T9cwQtpjEhXvr2UBsIYGjjBKLt2d0 MXIB2csZJV5OucIKkmAT0JF4/ugfM0hCRGAfo8T2u9OYQBLMArISz7Y1gU0SBiratWoWI4gt ImAo8WbqHVYIW09ieu9koA0cHCwCqhKrZnqDhHkFfCVWrr4GVsIIdMT3U2ugRopL3Hoynwni OAGJJXvOQx0qKvHy8T9WCFtZYsmT/SwQ9ToSC3Z/YoOwrSXu7DgKNUdbYtnC18wQuwQlTs58 wjKBUXQWkhWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxluYgTG1zEJNscdjAs+WR5ilOZg URLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY85LnuNpoR0N+YVXFl6UXzzT2WnJ iaA0wT3Tlf8JnhY2a/2ua87oPIn5q5/f9O9frM+/rp4YvMp5s+P/RTLVfb8maCTXqiae5D08 wVcruH3bs3937JgvJ2keud0/76Gs/cOzWvNfP1tqb5UWvtF3a0S66xnboxP9rubXB20zW+U7 I+31w6lC3kosxRmJhlrMRcWJAPvUcHp9AgAA Cc: OSPF List Subject: [OSPF] OSPF WG IETF 88 Preliminary Agenda X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 11:48:22 -0000 The preliminary OSPF WG agenda has been posted and we've been able to inclu= de all requests. While the agenda looks as if we have a lot of time to spar= e, history had proven that the 10 minute slots go very quickly.=20 https://datatracker.ietf.org/meeting/88/agenda/ospf/ Note that the IETF 88 Agenda page https://datatracker.ietf.org/meeting/88/a= genda.html has a nice feature where you can get all the drafts for a WG in = a pdf or tar ball.=20 Please read the draft before the meeting. If you don't read the drafts, you= are still welcome to come to session - just sit near the front and raise y= our hands whenever I raise mine ;^).=20 Thanks, Acee From asmirnov@cisco.com Wed Oct 23 05:09:22 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A8111E8361 for ; Wed, 23 Oct 2013 05:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgCeUUw6Jcg5 for ; Wed, 23 Oct 2013 05:09:17 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5D511E818B for ; Wed, 23 Oct 2013 05:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1382530155; x=1383739755; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2vlXhgApCs2IChMyVKPKtLZGsUL7VTgjSFuOH+fsJkQ=; b=dsSDovgvYddU1P3qDZt4IY+dUqsrk3bUiml1KCNC+cLB7mTK02wI4VHu qk0K3bDBaMMxIy+7gd4f2dzpshX8qsQG0BPrLOKDrZztEbkty/GEtqxaX 0b+lQ93Uyy86dkh9NwgipJ7dJxl074So0V8Qrsmk4BLuKyWbDvp5ZFaDQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALS7Z1KQ/khN/2dsb2JhbABZgwe8X4J6gScWdIIlAQEBBDg/AQEQCxgJFg8JAwIBAgFFBg0BBwEBiAK7EY4QgT4HhCoDmAmSB4FmgUA6gS0 X-IronPort-AV: E=Sophos;i="4.93,554,1378857600"; d="scan'208";a="18952898" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 23 Oct 2013 12:09:13 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9NC98ml015289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Oct 2013 12:09:11 GMT Message-ID: <5267BC64.9090804@cisco.com> Date: Wed, 23 Oct 2013 14:09:08 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE47030A1CA2@eusaamb101.ericsson.se> <5266D691.703@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE47030A3CE3@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A3CE3@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Cc: OSPF List , Harish Raghuveer , Rob Shakir Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 12:09:22 -0000 Hi Acce, you are just not formulating your objections in the correct way. For example, if specification said that Tag TLV must not exceed 64 Kb in size that would technically put a bound but this would be both pointless and wouldn't satisfy you. Another part is why RI LSA is being singled out - why unbound data in, say, Network LSA is OK and unbound data in RI LSA is not? Especially given that RI LSA can be extended to the adjacent LSIDs and the Network LSA cannot. Tag data ARE expected to be very small and very stable, so the choice of RI LSA to advertise them is very reasonable. Anton On 10/22/2013 10:05 PM, Acee Lindem wrote: > I don't disagree that the typical use case is a single tag with the > likelihood of mult-tag use cases diminishing exponentially as the > number of tags increases. My point is that unbounded TLVs MUST NOT be > included in the OSPF RI LSA. What part of that is hard to > understand? I think that 16 is a reasonable maximum and that beyond > 16 would imply encoding ulterior information that should have its own > TLV or LSA anyway. Acee > > On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote: > >> Hi Acee, it looks to me that the most probable deployment will use >> 1 tag. Router advertising 100 tags already sounds unreasonable. >> Defining new LSID to originate LSA with (typically) only 4 bytes of >> useful information is not optimal. Choice of RI LSA to advertise >> some small data is reasonable. RI LSA is far from getting too big. >> If there is a concern of RI LSA overfilling then we can extend >> range of opaque IDs - but is it really necessary at this point? >> >> Anton >> >> >> On 10/21/2013 09:55 PM, Acee Lindem wrote: >>> I think we are in a circular argument here and I'm not discuss >>> this independently with each of the authors. Either you have to >>> limit the number of tags, define a new LSA, or do the work to >>> make RI LSA multi-instance. All are viable alternatives with >>> differing pros and cons - including it in the existing RI LSA is >>> not a viable alternative. Remember to request a session if you >>> plan to present it at IETF 88. >>> >>> Thanks, Acee From acee.lindem@ericsson.com Wed Oct 23 15:44:49 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB79D11E827D for ; Wed, 23 Oct 2013 15:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NShSqL32vGNB for ; Wed, 23 Oct 2013 15:44:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 20C9311E8293 for ; Wed, 23 Oct 2013 15:44:40 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-b7-52685157442d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 49.E7.03458.75158625; Thu, 24 Oct 2013 00:44:39 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 18:44:38 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzpeJzDT6ZhHmikK259DG9ZYkD5oBZUCAgAAEogCAAQ1WAIAAPDqA Date: Wed, 23 Oct 2013 22:44:38 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A6406@eusaamb101.ericsson.se> In-Reply-To: <5267BC64.9090804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <66F249EA960E7A41AC01D44D0953010D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPlG54YEaQQd93aYuWbawWzZc2s1u0 3LvHbrHn3VpGixuP9jI7sHq0fZnM5DHl90ZWjyVLfjJ5XG+6yh7AEsVlk5Kak1mWWqRvl8CV 0bh2BmtBj1jF+4lrmBoYlwp2MXJySAiYSBzs6GCCsMUkLtxbz9bFyMUhJHCUUeJExxooZzmj xMrLc9hBqtgEdCSeP/rHDGKLCKhJbL77iRWkiFlgMqPEnCuvgYo4OIQFMiX+X/cDMUUEsiTa 15pAlLtJnNh8jRUkzCKgKjF1EiNImFfAV2Lu3ilgEzkFNCU2nvkDFmcEuuf7qTVgtzELiEvc ejIf6k4BiSV7zjND2KISLx//YwWxRQX0JLpnLWeFiCtLLHmynwWiV0diwe5PbBC2tcTd31Og ZmpLLFv4mhniBkGJkzOfsExgFJ+FZN0sJO2zkLTPQtI+C0n7AkbWVYwcpcWpZbnpRoabGIEx eEyCzXEH44JPlocYpTlYlMR5v7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA2KS84snl x/P31jX67wxiUBLf4r747c6Vtzwjdv6YKq9QybHy/H0Jrw1PX7tej3V8f7SILWbbH37Jr0ui +6pX1cmqhBzMjzwrNpdb4ou50Pw7E36zhEav856kb/ZykufqcMeIu48idN9XlexrdmtPnrMo p1Hj1l2DJ74cDFmyai+aclfn3nk3V4mlOCPRUIu5qDgRAFafmP2PAgAA Cc: OSPF List , Harish Raghuveer , Rob Shakir Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 22:44:50 -0000 Hi Anton, On 10/23/13 5:09 AM, "Anton Smirnov" wrote: > Hi Acce, > you are just not formulating your objections in the correct way. For >example, if specification said that Tag TLV must not exceed 64 Kb in >size that would technically put a bound but this would be both pointless >and wouldn't satisfy you. The applicability statement in section 3 of RFC 4970 is clear. It has nothing to do with how I formulate my objections ;^) > > Another part is why RI LSA is being singled out - why unbound data >in, say, Network LSA is OK and unbound data in RI LSA is not? Especially >given that RI LSA can be extended to the adjacent LSIDs and the Network >LSA cannot. This is a terrible analogy. The Network LSA has a single purpose and is bounded by the number of OSPF routers on a LAN. In this case, the TLV has no bound and implementors could come up with all sorts of clever ways to encode the data.=20 > > Tag data ARE expected to be very small and very stable, so the >choice of RI LSA to advertise them is very reasonable. I've heard requirements that contradict this statement in this E-mail thread.=20 Thanks, Acee=20 > >Anton > > >On 10/22/2013 10:05 PM, Acee Lindem wrote: >> I don't disagree that the typical use case is a single tag with the >> likelihood of mult-tag use cases diminishing exponentially as the >> number of tags increases. My point is that unbounded TLVs MUST NOT be >> included in the OSPF RI LSA. What part of that is hard to >> understand? I think that 16 is a reasonable maximum and that beyond >> 16 would imply encoding ulterior information that should have its own >> TLV or LSA anyway. Acee >> >> On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote: >> >>> Hi Acee, it looks to me that the most probable deployment will use >>> 1 tag. Router advertising 100 tags already sounds unreasonable. >>> Defining new LSID to originate LSA with (typically) only 4 bytes of >>> useful information is not optimal. Choice of RI LSA to advertise >>> some small data is reasonable. RI LSA is far from getting too big. >>> If there is a concern of RI LSA overfilling then we can extend >>> range of opaque IDs - but is it really necessary at this point? >>> >>> Anton >>> >>> >>> On 10/21/2013 09:55 PM, Acee Lindem wrote: >>>> I think we are in a circular argument here and I'm not discuss >>>> this independently with each of the authors. Either you have to >>>> limit the number of tags, define a new LSA, or do the work to >>>> make RI LSA multi-instance. All are viable alternatives with >>>> differing pros and cons - including it in the existing RI LSA is >>>> not a viable alternative. Remember to request a session if you >>>> plan to present it at IETF 88. >>>> >>>> Thanks, Acee > From acee.lindem@ericsson.com Wed Oct 23 15:47:14 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED79811E8286 for ; Wed, 23 Oct 2013 15:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBiQ5k2D4kRG for ; Wed, 23 Oct 2013 15:47:08 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D799B11E8282 for ; Wed, 23 Oct 2013 15:47:07 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-0d-526851ebe6cd Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1A.F7.03458.BE158625; Thu, 24 Oct 2013 00:47:07 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 18:47:06 -0400 From: Acee Lindem To: Hannes Gredler Thread-Topic: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt Thread-Index: AQHOzpeJzDT6ZhHmikK259DG9ZYkD5oBZUCAgAAEogCAAL6jgIAAi52A Date: Wed, 23 Oct 2013 22:47:05 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A6430@eusaamb101.ericsson.se> In-Reply-To: <20131023072727.GA12319@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <6578BFCC1E74FC4198D40D8DA418DA8C@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPgu7rwIwgg7cv5CxatrFa9N97wmbR fGkzu0XLvXvsFnverWV0YPVo+zKZyWPK742sHkuW/GTyuN50lT2AJYrLJiU1J7MstUjfLoEr 49WdKUwF67Mrep7vYW5gPBbQxcjJISFgInH3yyJmCFtM4sK99WxdjFwcQgJHGSVWNXUyQjjL GSV+XvnLBlLFJqAj8fzRP7AOEQF1iYWT7jKDFDELTGCUeLFyLVAHB4ewQKbE/+t+IKaIQJZE +1oTCNNNYtUsb5BOFgFVifXL74BN4RXwlej/fYkJpIRTwFDi6sJEkDAj0DnfT61hArGZBcQl bj2ZzwRxpoDEkj3noU4WlXj5+B8riC0qoCfRPWs5K0RcWWLJk/0sEL06Egt2f2IDGc8sYC2x 44cCRFhbYtnC11AXCEqcnPmEZQKj+Cwk22Yh6Z6F0D0LSfcsJN0LGFlXMXKUFqeW5aYbGW5i BEbfMQk2xx2MCz5ZHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjrKnP PkZqi13+IcijYag//9fq5vzHu6+kiu3OCJ29+l+x2o8d7EIz27a+t3y66MD2/YechWuO+Os+ tDx2QOk1i8vlg8GxOvwFCq5HOOIOZDTazlR684LzuRZvXEF1lPVsn8T9xrKPti7/yuOhZRqS G/+w7n87r7KE+0rtxUdXc23bYd9tG3hIiaU4I9FQi7moOBEAuyZaoYwCAAA= Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 22:47:14 -0000 Hannes,=20 On 10/23/13 12:27 AM, "Hannes Gredler" wrote: >acee, > >i think that 16 is an unreasonable max threshold as we have proof point >(e.g. link-colors) >that even 32 colors are not enough - so support for 64 colors is the bare >minimum >that SPs are looking for. >i fail to see the threat of overfilling the RI, with worst case 400 bytes >(100 colors). >furthermore it is an upper boundary number ... Will this limit be in the next revision of the draft? Thanks, Acee > >/hannes > >On Tue, Oct 22, 2013 at 08:05:09PM +0000, Acee Lindem wrote: >| I don't disagree that the typical use case is a single tag with the >likelihood of mult-tag use cases diminishing exponentially as the number >of tags increases. My point is that unbounded TLVs MUST NOT be included >in the OSPF RI LSA. What part of that is hard to understand? >| I think that 16 is a reasonable maximum and that beyond 16 would imply >encoding ulterior information that should have its own TLV or LSA anyway. >| Acee=20 >|=20 >| On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote: >|=20 >| > Hi Acee, >| > it looks to me that the most probable deployment will use 1 tag. >Router advertising 100 tags already sounds unreasonable. >| > Defining new LSID to originate LSA with (typically) only 4 bytes of >useful information is not optimal. Choice of RI LSA to advertise some >small data is reasonable. >| > RI LSA is far from getting too big. If there is a concern of RI LSA >overfilling then we can extend range of opaque IDs - but is it really >necessary at this point? >| >=20 >| > Anton >| >=20 >| >=20 >| > On 10/21/2013 09:55 PM, Acee Lindem wrote: >| >> I think we are in a circular argument here and I'm not discuss this >| >> independently with each of the authors. Either you have to limit the >| >> number of tags, define a new LSA, or do the work to make RI LSA >| >> multi-instance. All are viable alternatives with differing pros and >cons - >| >> including it in the existing RI LSA is not a viable alternative. >Remember >| >> to request a session if you plan to present it at IETF 88. >| >> Thanks, >| >> Acee >| >>=20 >| >> On 10/21/13 12:49 PM, "Shraddha Hegde" wrote: >| >>=20 >| >>> The "Applicability" section of the draft talks about why RI LSA is >chosen >| >>> as the node-tag TLV carrier instead of TE LSA. >| >>>=20 >| >>> The point I am trying make here is, if the link-color is carried in >a TLV, >| >>> Node color could also be carried in TLV and we don't need a new LSA >for >| >>> that. >| >>>=20 >| >>> Rgds >| >>> Shraddha >| >>>=20 >| >>> -----Original Message----- >| >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >| >>> Sent: Tuesday, October 22, 2013 12:53 AM >| >>> To: Shraddha Hegde >| >>> Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish >Raghuveer >| >>> Subject: Re: [OSPF] Review Request: New Version Notification for >| >>> draft-hegde-ospf-node-admin-tag-00.txt >| >>>=20 >| >>>=20 >| >>> On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: >| >>>=20 >| >>>> Actually, I think separate LSAs is a better alternative. >| >>>>=20 >| >>>> Node-tag is a just another property of the node. >OSPFv2/v3 >| >>>> have achieved the desired functionality using numerous link/node >| >>>> properties using TLVs in TE-LSA so I don't see an absolute >necessity of >| >>>> going with a new LSA. >| >>>=20 >| >>> Shraddha - If you think the Router-Information LSA is the same as >the TE >| >>> LSA you have not read RFC 4970. >| >>>=20 >| >>> Acee >| >>>=20 >| >>>=20 >| >>>>=20 >| >>>> Rgds >| >>>> Shraddha >| >>>>=20 >| >>>> -----Original Message----- >| >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >Behalf >| >>>> Of Acee Lindem >| >>>> Sent: Monday, October 21, 2013 8:55 PM >| >>>> To: Hannes Gredler >| >>>> Cc: OSPF List; Rob Shakir; Harish Raghuveer >| >>>> Subject: Re: [OSPF] Review Request: New Version Notification for >| >>>> draft-hegde-ospf-node-admin-tag-00.txt >| >>>>=20 >| >>>>=20 >| >>>> On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: >| >>>>=20 >| >>>>> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: >| >>>>> | >| >>>>> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: >| >>>>> | >| >>>>> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem >wrote: >| >>>>> | | Hannes, >| >>>>> | | >| >>>>> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: >| >>>>> | | >| >>>>> | | > acee, >| >>>>> | | > >| >>>>> | | > why should we give an upper boundary on things which >| >>>>> | | > - might be subject to change and >| >>>>> | | > - which have a historic track record of being >| >>>>> underestimated. >| >>>>> | | >| >>>>> | | You don't have to - just request a separate OSPFv2 >opaque LSA >| >>>>> and >| >>>>> | IPv6 OSPFv3 LSA from IANA. >| >>>>> | | Another alternative would be to extend the RI LSA to be >multi- >| >>>>> | instance and relegate the variable length tags to an >instance >| >>>>> other >| >>>>> | than instance 0. >| >>>>> | >| >>>>> | again the question why i do have to ? >| >>>>> | i can perfectly fit in single-digit as well as a few >dozens of >| >>>>> colors >| >>>>> | in a single RI LSA >| >>>>> | - what is your concern - except that we may use >inappropriate >| >>>>> large >| >>>>> | space for TE ? >| >>>>> | any reasonable implementation SHOULD restrict the node >color >| >>>>> set, >| >>>>> | such >| >>>>> | that overwhelming the 64K of RI LSPs is not going to >happen. >| >>>>> | >| >>>>> | We don't want a standard that leaves room for >| >>>>> | "unreasonable" implementations ;^). I think the >policy in >| >>>>> | RFC 4970 is clear. Here is an >| >>>>> | excerpt: >| >>>>>=20 >| >>>>> oh boy - i wish i could let the non-sense disappear just with good >| >>>>> standard docs ;-) - but i hear you - so all you're asking for is >an >| >>>>> upper boundary ? - is 128 low enough to not scare you and be >| >>>>> compliant to the below paragraph. >| >>>>=20 >| >>>> Actually, I think separate LSAs is a better alternative. >| >>>>=20 >| >>>>=20 >| >>>>=20 >| >>>>>=20 >| >>>>> | 3. Router Information LSA Opaque Usage and Applicability >| >>>>> | >| >>>>> | 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. The intent is to both limit the size of the RI >LSA >| >>>>> to >| >>>>> | the point where an OSPF router will always be able to >contain the >| >>>>> | TLVs in a single LSA and to keep the task of determining >what has >| >>>>> | changed between LSA instances reasonably simple. Hence, >| >>>>> discretion >| >>>>> | and sound engineering judgment will need to be applied when >| >>>>> deciding >| >>>>> | whether newly proposed TLV(s) in support of a new >application are >| >>>>> | advertised in the RI LSA or warrant the creation of an >application >| >>>>> | specific LSA. >| >>>>> | >| >>>>> | >| >>>>> | Anyway, this hasn't even been presented or accepted as a WG >| >>>>> document. >| >>>>>=20 >| >>>>> which is not a reason why we should not discuss how to iron out >the >| >>>>> bumpy parts now. >| >>>>=20 >| >>>> Right. >| >>>>=20 >| >>>> Thanks, >| >>>> Acee >| >>>>=20 >| >>>>=20 >| >>>>>=20 >| >>>>> thanks ! >| >>>>>=20 >| >>>>> /hannes >| >>>>>=20 >| >>>>> | | > the 'per-link' admin-groups serve as a good example >here: >| >>>>> | | > initially conceived as "you won't ever need more >than >| >>>>> | 32" we have >| >>>>> | | > now arrived at a variable length (unbounded) extension. >| >>>>> | | > >| >>>>> | | > >| >>>>> http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- >| >>>>> | groups-00 >| >>>>> | | > >| >>>>> | | > for a humorous take to it, have a look at >| >>>>> | | > http://tools.ietf.org/html/rfc1925 >| >>>>> | | > rule (9) and (10) >| >>>>> | | > >| >>>>> | | > /hannes >| >>>>> | | > >| >>>>> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: >| >>>>> | | > >| >>>>> | | >> Hi Shraddha, >| >>>>> | | >> Since the size of the tag data is unbounded, could you >| >>>>> either >| >>>>> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or >limit >| >>>>> the >| >>>>> | size to some maximum number of tags, e.g., 16? >| >>>>> | | >> Thanks, >| >>>>> | | >> Acee >| >>>>> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: >| >>>>> | | >> >| >>>>> | | >>> Hi All, >| >>>>> | | >>> >| >>>>> | | >>> We have posted a draft on " Advertising per-node >| >>>>> | administrative tags in OSPF" and would like to hear >your >| >>>>> views >| >>>>> | on it. Please feel free to raise any suggestion/comment on >the >| >>>>> | content. >| >>>>> | | >>> >| >>>>> | | >>> Rgds >| >>>>> | | >>> Shraddha >| >>>>> | | >>> >| >>>>> | | >>> -----Original Message----- >| >>>>> | | >>> From: internet-drafts@ietf.org [mailto:internet- >| >>>>> | drafts@ietf.org] >| >>>>> | | >>> Sent: Monday, October 21, 2013 4:24 PM >| >>>>> | | >>> To: Harish Raghuveer; Shraddha Hegde; British >Telecom; >| >>>>> Hannes >| >>>>> | Gredler; Rob Shakir >| >>>>> | | >>> Subject: New Version Notification for >| >>>>> draft-hegde-ospf-node- >| >>>>> | admin-tag-00.txt >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> A new version of I-D, >| >>>>> draft-hegde-ospf-node-admin-tag-00.txt >| >>>>> | | >>> has been successfully submitted by Shraddha Hegde and >| >>>>> posted to >| >>>>> | the IETF repository. >| >>>>> | | >>> >| >>>>> | | >>> Filename: draft-hegde-ospf-node-admin-tag >| >>>>> | | >>> Revision: 00 >| >>>>> | | >>> Title: Advertising per-node administrative tags in >OSPF >| >>>>> | | >>> Creation date: 2013-10-21 >| >>>>> | | >>> Group: Individual Submission >| >>>>> | | >>> Number of pages: 6 >| >>>>> | | >>> URL: >| >>>>> http://www.ietf.org/internet-drafts/draft- >| >>>>> | hegde-ospf-node-admin-tag-00.txt >| >>>>> | | >>> Status: >| >>>>> http://datatracker.ietf.org/doc/draft-hegde- >| >>>>> | ospf-node-admin-tag >| >>>>> | | >>> Htmlized: >| >>>>> http://tools.ietf.org/html/draft-hegde-ospf- >| >>>>> | node-admin-tag-00 >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> Abstract: >| >>>>> | | >>> This document describes an extension to OSPF protocol >| >>>>> [RFC2328] >| >>>>> | to >| >>>>> | | >>> add an optional operational capability, that allows >| >>>>> tagging and >| >>>>> | | >>> grouping of the nodes in an OSPF domain. This allows >| >>>>> | | >>> simplification,ease of management and control over >route >| >>>>> and >| >>>>> | path >| >>>>> | | >>> selection based on configured policies. >| >>>>> | | >>> >| >>>>> | | >>> This document describes the protocol extensions to >| >>>>> disseminate >| >>>>> | per- >| >>>>> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> 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 >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> >| >>>>> | | >>> _______________________________________________ >| >>>>> | | >>> 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 >| >>>>> | | >> >| >>>>> | | >> >| >>>>> | | > >| >>>>> | | > >| >>>>> | | >| >>>>> | | >| >>>>> | | >| >>>>> | >| >>>>> | >| >>>>>=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 >| >>>>=20 >| >>>>=20 >| >>>>=20 >| >>>> _______________________________________________ >| >>>> OSPF mailing list >| >>>> OSPF@ietf.org >| >>>> https://www.ietf.org/mailman/listinfo/ospf >| >>>=20 >| >>>=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 >|=20 >|=20 > From hannes@juniper.net Fri Oct 25 08:25:06 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3011E82CB for ; Fri, 25 Oct 2013 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDqLfxMYjpK6 for ; Fri, 25 Oct 2013 08:24:52 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8879311E821D for ; Fri, 25 Oct 2013 08:24:50 -0700 (PDT) Received: from mail111-db8-R.bigfish.com (10.174.8.251) by DB8EHSOBE024.bigfish.com (10.174.4.87) with Microsoft SMTP Server id 14.1.225.22; Fri, 25 Oct 2013 15:24:49 +0000 Received: from mail111-db8 (localhost [127.0.0.1]) by mail111-db8-R.bigfish.com (Postfix) with ESMTP id 870782A011C; Fri, 25 Oct 2013 15:24:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dI98dI9371I936eI1454I146fIc430I542I1418I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail111-db8: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail111-db8 (localhost.localdomain [127.0.0.1]) by mail111-db8 (MessageSwitch) id 1382714687890068_21544; Fri, 25 Oct 2013 15:24:47 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.241]) by mail111-db8.bigfish.com (Postfix) with ESMTP id CB0C520041; Fri, 25 Oct 2013 15:24:47 +0000 (UTC) Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 25 Oct 2013 15:24:47 +0000 Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 25 Oct 2013 15:24:42 +0000 Date: Fri, 25 Oct 2013 17:24:37 +0200 From: Hannes Gredler To: Acee Lindem Message-ID: <20131025152436.GA7269@juniper.net> References: <20131023072727.GA12319@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A6430@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A6430@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: OSPF List , Rob Shakir , Harish Raghuveer Subject: Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 15:25:10 -0000 On Wed, Oct 23, 2013 at 10:47:05PM +0000, Acee Lindem wrote: | Hannes, | | On 10/23/13 12:27 AM, "Hannes Gredler" wrote: | | >acee, | > | >i think that 16 is an unreasonable max threshold as we have proof point | >(e.g. link-colors) | >that even 32 colors are not enough - so support for 64 colors is the bare | >minimum | >that SPs are looking for. | >i fail to see the threat of overfilling the RI, with worst case 400 bytes | >(100 colors). | >furthermore it is an upper boundary number ... | | Will this limit be in the next revision of the draft? yes; | >On Tue, Oct 22, 2013 at 08:05:09PM +0000, Acee Lindem wrote: | >| I don't disagree that the typical use case is a single tag with the | >likelihood of mult-tag use cases diminishing exponentially as the number | >of tags increases. My point is that unbounded TLVs MUST NOT be included | >in the OSPF RI LSA. What part of that is hard to understand? | >| I think that 16 is a reasonable maximum and that beyond 16 would imply | >encoding ulterior information that should have its own TLV or LSA anyway. | >| Acee | >| | >| On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote: | >| | >| > Hi Acee, | >| > it looks to me that the most probable deployment will use 1 tag. | >Router advertising 100 tags already sounds unreasonable. | >| > Defining new LSID to originate LSA with (typically) only 4 bytes of | >useful information is not optimal. Choice of RI LSA to advertise some | >small data is reasonable. | >| > RI LSA is far from getting too big. If there is a concern of RI LSA | >overfilling then we can extend range of opaque IDs - but is it really | >necessary at this point? | >| > | >| > Anton | >| > | >| > | >| > On 10/21/2013 09:55 PM, Acee Lindem wrote: | >| >> I think we are in a circular argument here and I'm not discuss this | >| >> independently with each of the authors. Either you have to limit the | >| >> number of tags, define a new LSA, or do the work to make RI LSA | >| >> multi-instance. All are viable alternatives with differing pros and | >cons - | >| >> including it in the existing RI LSA is not a viable alternative. | >Remember | >| >> to request a session if you plan to present it at IETF 88. | >| >> Thanks, | >| >> Acee | >| >> | >| >> On 10/21/13 12:49 PM, "Shraddha Hegde" wrote: | >| >> | >| >>> The "Applicability" section of the draft talks about why RI LSA is | >chosen | >| >>> as the node-tag TLV carrier instead of TE LSA. | >| >>> | >| >>> The point I am trying make here is, if the link-color is carried in | >a TLV, | >| >>> Node color could also be carried in TLV and we don't need a new LSA | >for | >| >>> that. | >| >>> | >| >>> Rgds | >| >>> Shraddha | >| >>> | >| >>> -----Original Message----- | >| >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] | >| >>> Sent: Tuesday, October 22, 2013 12:53 AM | >| >>> To: Shraddha Hegde | >| >>> Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish | >Raghuveer | >| >>> Subject: Re: [OSPF] Review Request: New Version Notification for | >| >>> draft-hegde-ospf-node-admin-tag-00.txt | >| >>> | >| >>> | >| >>> On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: | >| >>> | >| >>>> Actually, I think separate LSAs is a better alternative. | >| >>>> | >| >>>> Node-tag is a just another property of the node. | >OSPFv2/v3 | >| >>>> have achieved the desired functionality using numerous link/node | >| >>>> properties using TLVs in TE-LSA so I don't see an absolute | >necessity of | >| >>>> going with a new LSA. | >| >>> | >| >>> Shraddha - If you think the Router-Information LSA is the same as | >the TE | >| >>> LSA you have not read RFC 4970. | >| >>> | >| >>> Acee | >| >>> | >| >>> | >| >>>> | >| >>>> Rgds | >| >>>> Shraddha | >| >>>> | >| >>>> -----Original Message----- | >| >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On | >Behalf | >| >>>> Of Acee Lindem | >| >>>> Sent: Monday, October 21, 2013 8:55 PM | >| >>>> To: Hannes Gredler | >| >>>> Cc: OSPF List; Rob Shakir; Harish Raghuveer | >| >>>> Subject: Re: [OSPF] Review Request: New Version Notification for | >| >>>> draft-hegde-ospf-node-admin-tag-00.txt | >| >>>> | >| >>>> | >| >>>> On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: | >| >>>> | >| >>>>> On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: | >| >>>>> | | >| >>>>> | On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: | >| >>>>> | | >| >>>>> | On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem | >wrote: | >| >>>>> | | Hannes, | >| >>>>> | | | >| >>>>> | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: | >| >>>>> | | | >| >>>>> | | > acee, | >| >>>>> | | > | >| >>>>> | | > why should we give an upper boundary on things which | >| >>>>> | | > - might be subject to change and | >| >>>>> | | > - which have a historic track record of being | >| >>>>> underestimated. | >| >>>>> | | | >| >>>>> | | You don't have to - just request a separate OSPFv2 | >opaque LSA | >| >>>>> and | >| >>>>> | IPv6 OSPFv3 LSA from IANA. | >| >>>>> | | Another alternative would be to extend the RI LSA to be | >multi- | >| >>>>> | instance and relegate the variable length tags to an | >instance | >| >>>>> other | >| >>>>> | than instance 0. | >| >>>>> | | >| >>>>> | again the question why i do have to ? | >| >>>>> | i can perfectly fit in single-digit as well as a few | >dozens of | >| >>>>> colors | >| >>>>> | in a single RI LSA | >| >>>>> | - what is your concern - except that we may use | >inappropriate | >| >>>>> large | >| >>>>> | space for TE ? | >| >>>>> | any reasonable implementation SHOULD restrict the node | >color | >| >>>>> set, | >| >>>>> | such | >| >>>>> | that overwhelming the 64K of RI LSPs is not going to | >happen. | >| >>>>> | | >| >>>>> | We don't want a standard that leaves room for | >| >>>>> | "unreasonable" implementations ;^). I think the | >policy in | >| >>>>> | RFC 4970 is clear. Here is an | >| >>>>> | excerpt: | >| >>>>> | >| >>>>> oh boy - i wish i could let the non-sense disappear just with good | >| >>>>> standard docs ;-) - but i hear you - so all you're asking for is | >an | >| >>>>> upper boundary ? - is 128 low enough to not scare you and be | >| >>>>> compliant to the below paragraph. | >| >>>> | >| >>>> Actually, I think separate LSAs is a better alternative. | >| >>>> | >| >>>> | >| >>>> | >| >>>>> | >| >>>>> | 3. Router Information LSA Opaque Usage and Applicability | >| >>>>> | | >| >>>>> | 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. The intent is to both limit the size of the RI | >LSA | >| >>>>> to | >| >>>>> | the point where an OSPF router will always be able to | >contain the | >| >>>>> | TLVs in a single LSA and to keep the task of determining | >what has | >| >>>>> | changed between LSA instances reasonably simple. Hence, | >| >>>>> discretion | >| >>>>> | and sound engineering judgment will need to be applied when | >| >>>>> deciding | >| >>>>> | whether newly proposed TLV(s) in support of a new | >application are | >| >>>>> | advertised in the RI LSA or warrant the creation of an | >application | >| >>>>> | specific LSA. | >| >>>>> | | >| >>>>> | | >| >>>>> | Anyway, this hasn't even been presented or accepted as a WG | >| >>>>> document. | >| >>>>> | >| >>>>> which is not a reason why we should not discuss how to iron out | >the | >| >>>>> bumpy parts now. | >| >>>> | >| >>>> Right. | >| >>>> | >| >>>> Thanks, | >| >>>> Acee | >| >>>> | >| >>>> | >| >>>>> | >| >>>>> thanks ! | >| >>>>> | >| >>>>> /hannes | >| >>>>> | >| >>>>> | | > the 'per-link' admin-groups serve as a good example | >here: | >| >>>>> | | > initially conceived as "you won't ever need more | >than | >| >>>>> | 32" we have | >| >>>>> | | > now arrived at a variable length (unbounded) extension. | >| >>>>> | | > | >| >>>>> | | > | >| >>>>> http://tools.ietf.org/html/draft-osborne-mpls-extended-admin- | >| >>>>> | groups-00 | >| >>>>> | | > | >| >>>>> | | > for a humorous take to it, have a look at | >| >>>>> | | > http://tools.ietf.org/html/rfc1925 | >| >>>>> | | > rule (9) and (10) | >| >>>>> | | > | >| >>>>> | | > /hannes | >| >>>>> | | > | >| >>>>> | | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: | >| >>>>> | | > | >| >>>>> | | >> Hi Shraddha, | >| >>>>> | | >> Since the size of the tag data is unbounded, could you | >| >>>>> either | >| >>>>> | put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or | >limit | >| >>>>> the | >| >>>>> | size to some maximum number of tags, e.g., 16? | >| >>>>> | | >> Thanks, | >| >>>>> | | >> Acee | >| >>>>> | | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: | >| >>>>> | | >> | >| >>>>> | | >>> Hi All, | >| >>>>> | | >>> | >| >>>>> | | >>> We have posted a draft on " Advertising per-node | >| >>>>> | administrative tags in OSPF" and would like to hear | >your | >| >>>>> views | >| >>>>> | on it. Please feel free to raise any suggestion/comment on | >the | >| >>>>> | content. | >| >>>>> | | >>> | >| >>>>> | | >>> Rgds | >| >>>>> | | >>> Shraddha | >| >>>>> | | >>> | >| >>>>> | | >>> -----Original Message----- | >| >>>>> | | >>> From: internet-drafts@ietf.org [mailto:internet- | >| >>>>> | drafts@ietf.org] | >| >>>>> | | >>> Sent: Monday, October 21, 2013 4:24 PM | >| >>>>> | | >>> To: Harish Raghuveer; Shraddha Hegde; British | >Telecom; | >| >>>>> Hannes | >| >>>>> | Gredler; Rob Shakir | >| >>>>> | | >>> Subject: New Version Notification for | >| >>>>> draft-hegde-ospf-node- | >| >>>>> | admin-tag-00.txt | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> A new version of I-D, | >| >>>>> draft-hegde-ospf-node-admin-tag-00.txt | >| >>>>> | | >>> has been successfully submitted by Shraddha Hegde and | >| >>>>> posted to | >| >>>>> | the IETF repository. | >| >>>>> | | >>> | >| >>>>> | | >>> Filename: draft-hegde-ospf-node-admin-tag | >| >>>>> | | >>> Revision: 00 | >| >>>>> | | >>> Title: Advertising per-node administrative tags in | >OSPF | >| >>>>> | | >>> Creation date: 2013-10-21 | >| >>>>> | | >>> Group: Individual Submission | >| >>>>> | | >>> Number of pages: 6 | >| >>>>> | | >>> URL: | >| >>>>> http://www.ietf.org/internet-drafts/draft- | >| >>>>> | hegde-ospf-node-admin-tag-00.txt | >| >>>>> | | >>> Status: | >| >>>>> http://datatracker.ietf.org/doc/draft-hegde- | >| >>>>> | ospf-node-admin-tag | >| >>>>> | | >>> Htmlized: | >| >>>>> http://tools.ietf.org/html/draft-hegde-ospf- | >| >>>>> | node-admin-tag-00 | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> Abstract: | >| >>>>> | | >>> This document describes an extension to OSPF protocol | >| >>>>> [RFC2328] | >| >>>>> | to | >| >>>>> | | >>> add an optional operational capability, that allows | >| >>>>> tagging and | >| >>>>> | | >>> grouping of the nodes in an OSPF domain. This allows | >| >>>>> | | >>> simplification,ease of management and control over | >route | >| >>>>> and | >| >>>>> | path | >| >>>>> | | >>> selection based on configured policies. | >| >>>>> | | >>> | >| >>>>> | | >>> This document describes the protocol extensions to | >| >>>>> disseminate | >| >>>>> | per- | >| >>>>> | | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> 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 | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> | >| >>>>> | | >>> _______________________________________________ | >| >>>>> | | >>> 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 | >| >>>> | >| >>>> _______________________________________________ | >| >>>> 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 | >| >> | >| | >| _______________________________________________ | >| OSPF mailing list | >| OSPF@ietf.org | >| https://www.ietf.org/mailman/listinfo/ospf | >| | >| | > | | | From akr@cisco.com Fri Oct 25 10:48:56 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8911E819F; Fri, 25 Oct 2013 10:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-dzvTr7t945; Fri, 25 Oct 2013 10:48:51 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D38EB11E817B; Fri, 25 Oct 2013 10:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8921; q=dns/txt; s=iport; t=1382723331; x=1383932931; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=z83F9IRlx0ROvMHmgd3Khmk9X6nfplS5Z3H9oTlFtNU=; b=LlNBOJl0GKgQ0dk0t68/stxljuBzd0S5VQj9FgrEPz6gd7bQsnpxz4H+ +B+HyMCO4S0xzFGi0VdJu/ATSHhzcn6VuxBsotz2ufurnaCD3l46OuYJv 4FGjqiWp3M24ZWRVb2Ka0Gpof+bWgLLK7U3s1wUkSbsLygw6KIPcJx3bx o=; X-Files: ospf-wg-rfc6506bis-shepherd-writeup.txt : 6045 X-IronPort-AV: E=Sophos;i="4.93,571,1378857600"; d="txt'?scan'208";a="95593081" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Oct 2013 17:48:51 +0000 Received: from [10.154.204.234] ([10.154.204.234]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9PHmoJh007096; Fri, 25 Oct 2013 17:48:50 GMT Message-ID: <526AAF02.2040105@cisco.com> Date: Fri, 25 Oct 2013 10:48:50 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adrian Farrel , Stewart Bryant , ietf-secretariat@ietf.org References: <50F98F9F.3090008@cisco.com> In-Reply-To: <50F98F9F.3090008@cisco.com> Content-Type: multipart/mixed; boundary="------------010706060603060107030100" Cc: draft-ietf-ospf-rfc6506bis@tools.ietf.org, "ospf@ietf.org" Subject: [OSPF] Publication request for "Supporting Authentication Trailer for OSPFv3" - draft-ietf-ospf-rfc6506bis-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 17:48:56 -0000 This is a multi-part message in MIME format. --------------010706060603060107030100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Please publish draft-ietf-ospf-rfc6506bis-01.txt as a Proposed Standard. Shepherd writeup attached (also uploaded to the datatracker). Regards, -Abhay --------------010706060603060107030100 Content-Type: text/plain; charset=UTF-8; name="ospf-wg-rfc6506bis-shepherd-writeup.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ospf-wg-rfc6506bis-shepherd-writeup.txt" KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2Vk IFN0YW5kYXJkLCBJbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVu dGFsLCBvciBIaXN0b3JpYyk/IFdoeSBpcyB0aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/ IElzIHRoaXMgdHlwZSBvZiBSRkMgaW5kaWNhdGVkIGluIHRoZSB0aXRsZSBwYWdlIGhlYWRl cj8KCiAgIEludGVybmV0IFN0YW5kYXJkLCBSZXNwaW4gb2YgYSBTdGFuZGFyZHMgVHJhY2sg UkZDLCBZZXMKCigyKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMg YSBEb2N1bWVudCBBbm5vdW5jZW1lbnQgV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2gg YSBEb2N1bWVudCBBbm5vdW5jZW1lbnQgV3JpdGUtVXAuIFJlY2VudCBleGFtcGxlcyBjYW4g YmUgZm91bmQgaW4gdGhlICJBY3Rpb24iIGFubm91bmNlbWVudHMgZm9yIGFwcHJvdmVkIGRv Y3VtZW50cy4gVGhlIGFwcHJvdmFsIGFubm91bmNlbWVudCBjb250YWlucyB0aGUgZm9sbG93 aW5nIHNlY3Rpb25zOgoKVGVjaG5pY2FsIFN1bW1hcnk6CgogICBUaGlzIGRvY3VtZW50IGlz IGFuIHVwZGF0ZSB0byBSRkMgNjUwNi4gUHJpbWFyeSBtb3RpdmF0aW9uIHRvIHJlZnJlc2gg dGhlCiAgIFJGQyB3YXMgc29tZSBFcnJhdGEncyByYWlzZWQgd2hpY2ggcG9pbnRlZCB0b3dh cmRzIGFtYmlndWl0aWVzIGluIHRleHQuIFRoaXMKICAgdXBkYXRlIHByb3ZpZGVzIGNsZWFy IHJlY29tbWVuZGF0aW9ucyB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuCiAg IG11bHRpcGxlIGltcGxlbWVudGF0aW9ucy4KCldvcmtpbmcgR3JvdXAgU3VtbWFyeToKCiAg IFRoZXJlIHdhcyBzb21lIGdvb2QgZGlzY3Vzc2lvbiBhbW9uZyBFcnJhdGEgYXV0aG9ycyBh bmQgZG9jdW1lbnQgYXV0aG9ycyB0bwogICBjb21lIHRvIGNvbnNlbnN1cyBvbiBleGFjdCB0 ZXh0IGJlaW5nIGFkZGVkIGZvciB0aGUgbmVlZGVkIGNsYXJpZmljYXRpb24uCiAgIEFsc28g YSByZXZpZXcgd2FzIGRvbmUgd2l0aCBSYW4gQXRraW5zb24gYW5kIFNlYW4gVHVybmVyIGZv ciBzb21lIHRleHQKICAgY2hhbmdlIGFyb3VuZCBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0 aW9uIFByb2NlZHVyZS4KCkRvY3VtZW50IFF1YWxpdHk6CgogICBUaGUgaW5jcmVtZW50YWwg dXBkYXRlIHRvIFJGQzY1MDYgYXJlIG1pbmltYWwgYW5kIGFyZSBwcmltYXJpbHkgdG8gY2xh cmlmeQogICBzb21lIHRleHQgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkuIAoKUGVyc29u bmVsOgoKICAgQWJoYXkgUm95IGlzIHRoZSBkb2N1bWVudCBzaGVwaGVyZCBhbmQgU3Rld2Fy dCBCcnlhbnQgaXMgdGhlIHJlc3BvbnNpYmxlIEFELiAKCgooMykgQnJpZWZseSBkZXNjcmli ZSB0aGUgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgdGhhdCB3YXMgcGVyZm9ybWVkIGJ5IHRo ZSBEb2N1bWVudCBTaGVwaGVyZC4gSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBp cyBub3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBwbGVhc2UgZXhwbGFpbiB3aHkgdGhlIGRv Y3VtZW50IGlzIGJlaW5nIGZvcndhcmRlZCB0byB0aGUgSUVTRy4KCiAgIFRoZSBkcmFmdCBp cyBhIG1pbmltYWwgdXBkYXRlIG9mIFJGQzMxMzcuIFRoZXJlIGhhcyBiZWVuIHNpZ25pZmlj YW50CiAgIHJldmlldyBhbmQgZGlzY3Vzc2lvbiBvZiB0aGlzIGRyYWZ0IG9uIHRoZSBtYWls aW5nIGxpc3QuIFRoZXJlIGFyZSBubwogICBvdXRzdGFuZGluZyBpc3N1ZXMgd2l0aCB0aGlz IGRyYWZ0LgoKKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IGNvbmNl cm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQgaGF2 ZSBiZWVuIHBlcmZvcm1lZD8KCiAgIE5vCgooNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRvY3Vt ZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb20gYnJvYWRlciBwZXJz cGVjdGl2ZSwgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIEFBQSwg RE5TLCBESENQLCBYTUwsIG9yIGludGVybmF0aW9uYWxpemF0aW9uPyBJZiBzbywgZGVzY3Jp YmUgdGhlIHJldmlldyB0aGF0IHRvb2sgcGxhY2UuCgogICBZZXMuIFNlY3VyaXR5IChSYW4g QXRraW5zb24gYW5kIFNlYW4gVHVybmVyIGRpZCB0aGUgcmV2aWV3KSAKCig2KSBEZXNjcmli ZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNo ZXBoZXJkIGhhcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgUmVzcG9uc2libGUgQXJl YSBEaXJlY3RvciBhbmQvb3IgdGhlIElFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3IgZXhh bXBsZSwgcGVyaGFwcyBoZSBvciBzaGUgaXMgdW5jb21mb3J0YWJsZSB3aXRoIGNlcnRhaW4g cGFydHMgb2YgdGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSBy ZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gSW4gYW55IGV2ZW50LCBpZiB0aGUgV0cgaGFzIGRp c2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3 aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQsIGRldGFpbCB0aG9zZSBjb25jZXJucyBo ZXJlLgoKICAgTm9uZQoKKDcpIEhhcyBlYWNoIGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkg YW5kIGFsbCBhcHByb3ByaWF0ZSBJUFIgZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwg Y29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OSBo YXZlIGFscmVhZHkgYmVlbiBmaWxlZC4gSWYgbm90LCBleHBsYWluIHdoeT8KCiAgIFllcwoK KDgpIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVkIHRoYXQgcmVmZXJlbmNlcyB0 aGlzIGRvY3VtZW50PyBJZiBzbywgc3VtbWFyaXplIGFueSBXRyBkaXNjdXNzaW9uIGFuZCBj b25jbHVzaW9uIHJlZ2FyZGluZyB0aGUgSVBSIGRpc2Nsb3N1cmVzLgoKICAgTm8gSVBScwoK KDkpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50 PyBEb2VzIGl0IHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGlu ZGl2aWR1YWxzLCB3aXRoIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFz IGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCBpdD8KCiAgIFN0cm9uZyBjb25z ZW5zdXMgZnJvbSBXRyB3aXRoIG1hbnkgcGFydGljaXBhdGluZyBpbiBkaXNjdXNzaW9ucy4K CigxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5k aWNhdGVkIGV4dHJlbWUgZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2UgdGhl IGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlIGVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBS ZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgc2hvdWxkIGJlIGluIGEgc2VwYXJhdGUg ZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkgYXZhaWxhYmxl LikKCiAgIE5vCgooMTEpIElkZW50aWZ5IGFueSBJRCBuaXRzIHRoZSBEb2N1bWVudCBTaGVw aGVyZCBoYXMgZm91bmQgaW4gdGhpcyBkb2N1bWVudC4gKFNlZSBodHRwOi8vd3d3LmlldGYu b3JnL3Rvb2xzL2lkbml0cy8gYW5kIHRoZSBJbnRlcm5ldC1EcmFmdHMgQ2hlY2tsaXN0KS4g Qm9pbGVycGxhdGUgY2hlY2tzIGFyZSBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRv IGJlIHRob3JvdWdoLgoKICAgTm8gaXNzdWVzIGZvdW5kIGJ5IGlkbml0cy4KCigxMikgRGVz Y3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBhbnkgcmVxdWlyZWQgZm9ybWFsIHJldmll dyBjcml0ZXJpYSwgc3VjaCBhcyB0aGUgTUlCIERvY3RvciwgbWVkaWEgdHlwZSwgYW5kIFVS SSB0eXBlIHJldmlld3MuCgogICBOb3QgYXBwbGljYWJsZQoKKDEzKSBIYXZlIGFsbCByZWZl cmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRpZmllZCBhcyBlaXRoZXIg bm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlPwoKICAgWWVzCgooMTQpIEFyZSB0aGVyZSBub3Jt YXRpdmUgcmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCBhcmUgbm90IHJlYWR5IGZvciBh ZHZhbmNlbWVudCBvciBhcmUgb3RoZXJ3aXNlIGluIGFuIHVuY2xlYXIgc3RhdGU/IElmIHN1 Y2ggbm9ybWF0aXZlIHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhlIHBsYW4gZm9yIHRo ZWlyIGNvbXBsZXRpb24/CgogICBObwoKKDE1KSBBcmUgdGhlcmUgZG93bndhcmQgbm9ybWF0 aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT8gSWYgc28sIGxpc3Qg dGhlc2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhIERpcmVjdG9y IGluIHRoZSBMYXN0IENhbGwgcHJvY2VkdXJlLgoKICAgTm8KCigxNikgV2lsbCBwdWJsaWNh dGlvbiBvZiB0aGlzIGRvY3VtZW50IGNoYW5nZSB0aGUgc3RhdHVzIG9mIGFueSBleGlzdGlu ZyBSRkNzPyBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQgb24gdGhlIHRpdGxlIHBhZ2UgaGVhZGVy LCBsaXN0ZWQgaW4gdGhlIGFic3RyYWN0LCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBpbnRyb2R1 Y3Rpb24/IElmIHRoZSBSRkNzIGFyZSBub3QgbGlzdGVkIGluIHRoZSBBYnN0cmFjdCBhbmQg SW50cm9kdWN0aW9uLCBleHBsYWluIHdoeSwgYW5kIHBvaW50IHRvIHRoZSBwYXJ0IG9mIHRo ZSBkb2N1bWVudCB3aGVyZSB0aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgZG9jdW1lbnQgdG8g dGhlIG90aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5v dCBpbiB0aGUgZG9jdW1lbnQsIGV4cGxhaW4gd2h5IHRoZSBXRyBjb25zaWRlcnMgaXQgdW5u ZWNlc3NhcnkuCgogICBZZXMKCigxNykgRGVzY3JpYmUgdGhlIERvY3VtZW50IFNoZXBoZXJk J3MgcmV2aWV3IG9mIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGVzcGVjaWFs bHkgd2l0aCByZWdhcmQgdG8gaXRzIGNvbnNpc3RlbmN5IHdpdGggdGhlIGJvZHkgb2YgdGhl IGRvY3VtZW50LiBDb25maXJtIHRoYXQgYWxsIHByb3RvY29sIGV4dGVuc2lvbnMgdGhhdCB0 aGUgZG9jdW1lbnQgbWFrZXMgYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUg cmVzZXJ2YXRpb25zIGluIElBTkEgcmVnaXN0cmllcy4gQ29uZmlybSB0aGF0IGFueSByZWZl cmVuY2VkIElBTkEgcmVnaXN0cmllcyBoYXZlIGJlZW4gY2xlYXJseSBpZGVudGlmaWVkLiBD b25maXJtIHRoYXQgbmV3bHkgY3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVkZSBhIGRl dGFpbGVkIHNwZWNpZmljYXRpb24gb2YgdGhlIGluaXRpYWwgY29udGVudHMgZm9yIHRoZSBy ZWdpc3RyeSwgdGhhdCBhbGxvY2F0aW9ucyBwcm9jZWR1cmVzIGZvciBmdXR1cmUgcmVnaXN0 cmF0aW9ucyBhcmUgZGVmaW5lZCwgYW5kIGEgcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3 IHJlZ2lzdHJ5IGhhcyBiZWVuIHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS4KCiAgIFRoZXJl IGlzIG5vIElBTkEgQWN0aW9uIG5lZWRlZC4gCgooMTgpIExpc3QgYW55IG5ldyBJQU5BIHJl Z2lzdHJpZXMgdGhhdCByZXF1aXJlIEV4cGVydCBSZXZpZXcgZm9yIGZ1dHVyZSBhbGxvY2F0 aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQgdGhlIElFU0cgd291bGQg ZmluZCB1c2VmdWwgaW4gc2VsZWN0aW5nIHRoZSBJQU5BIEV4cGVydHMgZm9yIHRoZXNlIG5l dyByZWdpc3RyaWVzLgoKICAgVGhlcmUgaXMgbm8gSUFOQSBBY3Rpb24gbmVlZGVkLiAKCigx OSkgRGVzY3JpYmUgcmV2aWV3cyBhbmQgYXV0b21hdGVkIGNoZWNrcyBwZXJmb3JtZWQgYnkg dGhlIERvY3VtZW50IFNoZXBoZXJkIHRvIHZhbGlkYXRlIHNlY3Rpb25zIG9mIHRoZSBkb2N1 bWVudCB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBzdWNoIGFzIFhNTCBjb2RlLCBC TkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywgZXRjLgoKICAgTm90IGFwcGxpY2FibGUK --------------010706060603060107030100-- From iesg-secretary@ietf.org Tue Oct 29 11:59:31 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D028C11E8293; Tue, 29 Oct 2013 11:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDuNs1E2nS4a; Tue, 29 Oct 2013 11:59:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7395811E819B; Tue, 29 Oct 2013 11:59:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131029185921.20757.41528.idtracker@ietfa.amsl.com> Date: Tue, 29 Oct 2013 11:59:21 -0700 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:59:32 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Supporting Authentication Trailer for OSPFv3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. This document obsoletes RFC 6506. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc6506bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc6506bis/ballot/ No IPR declarations have been submitted directly on this I-D.