Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt
Anton Smirnov <asmirnov@cisco.com> Tue, 22 October 2013 19:50 UTC
Return-Path: <asmirnov@cisco.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 D436411E821A for <ospf@ietfa.amsl.com>; 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 <ospf@ietfa.amsl.com>; 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 <ospf@ietf.org>; 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 <asmirnov@cisco.com>
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 <acee.lindem@ericsson.com>, Shraddha Hegde <shraddha@juniper.net>
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 <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: 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" <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 >>>> | "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] Review Request: New Version Notification f… Shraddha Hegde
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Hannes Gredler
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Hannes Gredler
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Hannes Gredler
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Shraddha Hegde
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Shraddha Hegde
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Anton Smirnov
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Hannes Gredler
- Re: [OSPF] Review Request: New Version Notificati… Anton Smirnov
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Acee Lindem
- Re: [OSPF] Review Request: New Version Notificati… Hannes Gredler