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

Hannes Gredler <hannes@juniper.net> Fri, 25 October 2013 15:25 UTC

Return-Path: <hannes@juniper.net>
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 00E3011E82CB for <ospf@ietfa.amsl.com>; Fri, 25 Oct 2013 08:25:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.194
X-Spam-Level:
X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 nDqLfxMYjpK6 for <ospf@ietfa.amsl.com>; Fri, 25 Oct 2013 08:24:52 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8879311E821D for <ospf@ietf.org>; Fri, 25 Oct 2013 08:24:50 -0700 (PDT)
Received: from mail111-db8-R.bigfish.com (10.174.8.251) by DB8EHSOBE024.bigfish.com (10.174.4.87) with Microsoft SMTP Server id 14.1.225.22; Fri, 25 Oct 2013 15:24:49 +0000
Received: from mail111-db8 (localhost [127.0.0.1]) by mail111-db8-R.bigfish.com (Postfix) with ESMTP id 870782A011C; Fri, 25 Oct 2013 15:24:49 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -31
X-BigFish: VPS-31(zzbb2dI98dI9371I936eI1454I146fIc430I542I1418I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h)
Received-SPF: pass (mail111-db8: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ;
Received: from mail111-db8 (localhost.localdomain [127.0.0.1]) by mail111-db8 (MessageSwitch) id 1382714687890068_21544; Fri, 25 Oct 2013 15:24:47 +0000 (UTC)
Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.241]) by mail111-db8.bigfish.com (Postfix) with ESMTP id CB0C520041; Fri, 25 Oct 2013 15:24:47 +0000 (UTC)
Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 25 Oct 2013 15:24:47 +0000
Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 25 Oct 2013 15:24:42 +0000
Date: Fri, 25 Oct 2013 17:24:37 +0200
From: Hannes Gredler <hannes@juniper.net>
To: Acee Lindem <acee.lindem@ericsson.com>
Message-ID: <20131025152436.GA7269@juniper.net>
References: <20131023072727.GA12319@juniper.net> <94A203EA12AECE4BA92D42DBFFE0AE47030A6430@eusaamb101.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A6430@eusaamb101.ericsson.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [193.110.54.36]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
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: Fri, 25 Oct 2013 15:25:10 -0000

On Wed, Oct 23, 2013 at 10:47:05PM +0000, Acee Lindem wrote:
| 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?

yes;


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