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

From: Shraddha Hegde <[email-masked]>
Date: Mon, 21 Oct 2013 11:05:25 +0000

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: [email-masked] [mailto:[email-masked]] 
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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 21 Oct 2013 13:12:27 +0000

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:

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Oct 2013 15:26:10 +0200

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.

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 21 Oct 2013 13:32:54 +0000

Hannes, 

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

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Oct 2013 15:51:53 +0200

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.

| > 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: [email-masked] [mailto:[email-masked]] 
| >>> 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
| >>> [email-masked]
| >>> https://www.ietf.org/mailman/listinfo/ospf
| >> 
| >> _______________________________________________
| >> OSPF mailing list
| >> [email-masked]
| >> https://www.ietf.org/mailman/listinfo/ospf
| >> 
| >> 
| > 
| > 
| 
| 
|

---

From: Acee Lindem <[email-masked]>
Date: Mon, 21 Oct 2013 14:10:04 +0000

On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote:

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

| >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
| >>> 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>.
| >>> [email-masked]<mailto:[email-masked]>
| >> [email-masked]<mailto:[email-masked]>

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Oct 2013 17:08:47 +0200

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

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: [email-masked] [mailto:internet-
|      [email-masked]]
|      | >>> 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
|      | >>> [email-masked]
|      | >>> https://www.ietf.org/mailman/listinfo/ospf
|      | >>
|      | >> _______________________________________________
|      | >> OSPF mailing list
|      | >> [email-masked]
|      | >> https://www.ietf.org/mailman/listinfo/ospf
|      | >>
|      | >>
|      | >
|      | >
|      |
|      |
|      |
| 
|

---

From: Acee Lindem <[email-masked]>
Date: Mon, 21 Oct 2013 11:24:40 -0400

> be compliant to the below paragraph.

Actually, I think separate LSAs is a better alternative. 

> which is not a reason why we should not discuss how to iron out the bumpy parts now.

Right.

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 21 Oct 2013 19:12:36 +0000

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

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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:

> | 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:
> 
> upper boundary ? - is 128 low enough to not scare you and be compliant 
> to the below paragraph.

Right.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Mon, 21 Oct 2013 19:22:58 +0000

> 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

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 21 Oct 2013 19:49:36 +0000

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:[email-masked]] 
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:

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

Acee 

>> upper boundary ? - is 128 low enough to not scare you and be 
>> compliant to the below paragraph.
>

---

From: Acee Lindem <[email-masked]>
Date: Mon, 21 Oct 2013 19:55:46 +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" <[email-masked]> wrote:

>The "Applicability" section of the draft talks about why RI LSA is chosen
>as the node-tag TLV carrier instead of TE LSA.
>
>> 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.
>
>>>http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-
>>> |      groups-00
>>> |      | >
>>> |      | >>> URL:
>>>http://www.ietf.org/internet-drafts/draft-
>>> |      | >>> 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:

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 22 Oct 2013 21:48:33 +0200

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

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Oct 2013 20:05:09 +0000

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

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 23 Oct 2013 09:27:27 +0200

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

/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" <[email-masked]> 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:[email-masked]]
| >>> 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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:internet-
| >>>>> |      [email-masked]]
| >>>>> |      | >>> 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
| >>>>> |      | >>> [email-masked]
| >>>>> |      | >>> https://www.ietf.org/mailman/listinfo/ospf
| >>>>> |      | >>
| >>>>> |      | >> _______________________________________________
| >>>>> |      | >> OSPF mailing list
| >>>>> |      | >> [email-masked]
| >>>>> |      | >> https://www.ietf.org/mailman/listinfo/ospf
| >>>>> |      | >>
| >>>>> |      | >>
| >>>>> |      | >
| >>>>> |      | >
| >>>>> |      |
| >>>>> |      |
| >>>>> |      |
| >>>>> |
| >>>>> |
| >>>>> 
| >>>>> _______________________________________________
| >>>>> OSPF mailing list
| >>>>> [email-masked]
| >>>>> https://www.ietf.org/mailman/listinfo/ospf
| >>>> 
| >>>> _______________________________________________
| >>>> OSPF mailing list
| >>>> [email-masked]
| >>>> https://www.ietf.org/mailman/listinfo/ospf
| >>>> 
| >>>> 
| >>>> 
| >>>> _______________________________________________
| >>>> OSPF mailing list
| >>>> [email-masked]
| >>>> https://www.ietf.org/mailman/listinfo/ospf
| >>> 
| >>> 
| >>> 
| >>> 
| >> 
| >> _______________________________________________
| >> OSPF mailing list
| >> [email-masked]
| >> https://www.ietf.org/mailman/listinfo/ospf
| >> 
| 
| _______________________________________________
| OSPF mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/ospf
| 
|

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 23 Oct 2013 14:09:08 +0200

Hi Acce,
    you are just not formulating your objections in the correct way. For 
example, if specification said that Tag TLV must not exceed 64 Kb in 
size that would technically put a bound but this would be both pointless 
and wouldn't satisfy you.

    Another part is why RI LSA is being singled out - why unbound data 
in, say, Network LSA is OK and unbound data in RI LSA is not? Especially 
given that RI LSA can be extended to the adjacent LSIDs and the Network 
LSA cannot.

    Tag data ARE expected to be very small and very stable, so the 
choice of RI LSA to advertise them is very reasonable.

Anton

On 10/22/2013 10:05 PM, 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
>
>> Hi Acee, it looks to me that the most probable deployment will use
>> 1 tag. Router advertising 100 tags already sounds unreasonable.
>> 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
>>
>>
>>> 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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 23 Oct 2013 22:44:38 +0000

Hi Anton,

>and wouldn't satisfy you.

The applicability statement in section 3 of RFC 4970 is clear. It has
nothing to do with how I formulate my objections ;^)

>given that RI LSA can be extended to the adjacent LSIDs and the Network

This is a terrible analogy. The Network LSA has a single purpose and is
bounded by the number of OSPF routers on a LAN. In this case, the TLV has
no bound and implementors could come up with all sorts of clever ways to
encode the data. 

>choice of RI LSA to advertise them is very reasonable.

I've heard requirements that contradict this statement in this E-mail
thread. 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 23 Oct 2013 22:47:05 +0000

Hannes, 

>furthermore it is an upper boundary number ...

Will this limit be in the next revision of the draft?

Thanks,
Acee

>| 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 
>| 
>| >   it looks to me that the most probable deployment will use 1 tag.
>| >   Defining new LSID to originate LSA with (typically) only 4 bytes of
>| >   RI LSA is far from getting too big. If there is a concern of RI LSA

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 25 Oct 2013 17:24:37 +0200

On Wed, Oct 23, 2013 at 10:47:05PM +0000, Acee Lindem wrote:
| Hannes, 
| 
| On 10/23/13 12:27 AM, "Hannes Gredler" <[email-masked]> 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" <[email-masked]> 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:[email-masked]]
| >| >>> 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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:internet-
| >| >>>>> |      [email-masked]]
| >| >>>>> |      | >>> 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
| >| >>>>> |      | >>> [email-masked]
| >| >>>>> |      | >>> https://www.ietf.org/mailman/listinfo/ospf
| >| >>>>> |      | >>
| >| >>>>> |      | >> _______________________________________________
| >| >>>>> |      | >> OSPF mailing list
| >| >>>>> |      | >> [email-masked]
| >| >>>>> |      | >> https://www.ietf.org/mailman/listinfo/ospf
| >| >>>>> |      | >>
| >| >>>>> |      | >>
| >| >>>>> |      | >
| >| >>>>> |      | >
| >| >>>>> |      |
| >| >>>>> |      |
| >| >>>>> |      |
| >| >>>>> |
| >| >>>>> |
| >| >>>>> 
| >| >>>>> _______________________________________________
| >| >>>>> OSPF mailing list
| >| >>>>> [email-masked]
| >| >>>>> https://www.ietf.org/mailman/listinfo/ospf
| >| >>>> 
| >| >>>> _______________________________________________
| >| >>>> OSPF mailing list
| >| >>>> [email-masked]
| >| >>>> https://www.ietf.org/mailman/listinfo/ospf
| >| >>>> 
| >| >>>> 
| >| >>>> 
| >| >>>> _______________________________________________
| >| >>>> OSPF mailing list
| >| >>>> [email-masked]
| >| >>>> https://www.ietf.org/mailman/listinfo/ospf
| >| >>> 
| >| >>> 
| >| >>> 
| >| >>> 
| >| >> 
| >| >> _______________________________________________
| >| >> OSPF mailing list
| >| >> [email-masked]
| >| >> https://www.ietf.org/mailman/listinfo/ospf
| >| >> 
| >| 
| >| _______________________________________________
| >| OSPF mailing list
| >| [email-masked]
| >| https://www.ietf.org/mailman/listinfo/ospf
| >| 
| >| 
| >
| 
| 
|