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

Acee Lindem <acee.lindem@ericsson.com> Wed, 23 October 2013 22:47 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 ED79811E8286 for <ospf@ietfa.amsl.com>; 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 <ospf@ietfa.amsl.com>; 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 <ospf@ietf.org>; 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 <acee.lindem@ericsson.com>
To: Hannes Gredler <hannes@juniper.net>
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 <ospf@ietf.org>, Rob Shakir <rob.shakir@bt.com>, Harish Raghuveer <hraghuveer@juniper.net>
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: Wed, 23 Oct 2013 22:47:14 -0000

Hannes, 

On 10/23/13 12:27 AM, "Hannes Gredler" <hannes@juniper.net> 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 
>| 
>| 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
>| >> 
>| 
>| _______________________________________________
>| OSPF mailing list
>| OSPF@ietf.org
>| https://www.ietf.org/mailman/listinfo/ospf
>| 
>| 
>