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

Acee Lindem <acee.lindem@ericsson.com> Mon, 21 October 2013 19:57 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 7D13E11E86C9 for <ospf@ietfa.amsl.com>; 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 <ospf@ietfa.amsl.com>; 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 <ospf@ietf.org>; 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 <acee.lindem@ericsson.com>
To: Shraddha Hegde <shraddha@juniper.net>
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: <a7fe1ca5fbde4befb1f89a64415a4279@BY2PR05MB127.namprd05.prod.outlook.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: <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 <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: 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 

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
>
>
>
>