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 14:10 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 F03D111E8573 for <ospf@ietfa.amsl.com>; 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 <ospf@ietfa.amsl.com>; 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 <ospf@ietf.org>; 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 <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: 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 <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 14:10:14 -0000

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:

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 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> [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<http://tools.ietf.org>.
| >>>
| >>> The IETF Secretariat
| >>>
| >>>
| >>>
| >>> _______________________________________________
| >>> OSPF mailing list
| >>> OSPF@ietf.org<mailto:OSPF@ietf.org>
| >>> https://www.ietf.org/mailman/listinfo/ospf
| >>
| >> _______________________________________________
| >> OSPF mailing list
| >> OSPF@ietf.org<mailto:OSPF@ietf.org>
| >> https://www.ietf.org/mailman/listinfo/ospf
| >>
| >>
| >
| >
|
|
|