Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt

Acee Lindem <acee.lindem@ericsson.com> Tue, 22 October 2013 20:05 UTC

Return-Path: <acee.lindem@ericsson.com>
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 <ospf@ietfa.amsl.com>; 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 <ospf@ietfa.amsl.com>; 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 <ospf@ietf.org>; 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 <acee.lindem@ericsson.com>
To: Anton Smirnov <asmirnov@cisco.com>
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: <ADEA52E4634CA34BB05FAFAC9B94B881@ericsson.com>
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 <ospf@ietf.org>, Harish Raghuveer <hraghuveer@juniper.net>, Rob Shakir <rob.shakir@bt.com>
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 <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2013 20:05:31 -0000

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" <shraddha@juniper.net> 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:
>>> 
>>>> <Acee> Actually, I think separate LSAs is a better alternative.
>>>> 
>>>> <Shraddha> 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
>>>>> | &quot;unreasonable&quot; 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 &quot;you won't ever need more than
>>>>> |      32&quot; 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 &quot; Advertising per-node
>>>>> |      administrative tags in OSPF&quot; 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
>>