Subject: Re: [Isis-wg] RE: Comments on <draft-ietf-isis-admin-tages-01.txt>

From: Hannes Gredler <[email-masked]>
Date: Sun, 25 May 2003 17:03:31 +0200

pls, keep in mind that there is already code in production that allows
more than one tag;

common use i have seen so far is

tag #1 controls L2L1 leakage
tag #2 for informational purposes and points to the area of origin;

/hannes

On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote:
| RE: Comments on <draft-ietf-isis-admin-tages-01.txt>
| 
| Acee,
| 
| As the original goal was to create a capability similar to OSPF's route tag,
| it may be wise to drop this capability.  On the otherhand, having multiple
| tags per route can provide more information about the route than a single
| tag.  In this regard, the 32 bit tag operates more like a community, and the
| 64 bit tag operates like an extended community.  From an implementation
| perspective, the same routines for matching and setting these fields should
| be similar to the community fields in BGP.
| 
| I would like to solicit the WG for comments on which capability is most
| attractive.  The goal is not to introduce too much bloat (is it too late for
| that?!) while still providing some flexibility.
| 
| As soon as I receive any final comments, I will release the updated draft.
| 
| Thanks for pointing out this critical piece!
| 
| Regards,
| chris
| 
| >-----Original Message-----
| >From: Acee Lindem [mailto:[email-masked]]
| >Sent: Friday, May 23, 2003 1:50 PM
| >To: Acee Lindem
| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area
| >Directorate
| >Subject: Re: Comments on <draft-ietf-isis-admin-tages-01.txt>
| >
| >
| >Christian, Stefano, Brad,
| >
| >The follow-up discussion on the necessity for both 32 bit and
| >64 bit tags raises the question as to whether or not it is
| >wise to allow an arbitrary number of tags to be advertised.
| >
| >       This draft proposes 2 new "Administrative Tag" sub-TLVs
| >to be added
| >       to TLV 135 and 235.  These TLVs specify one or more
| >ordered, 32 or 64
| >                                                  ~~~~~~~~~~~~~~~
| >       bit unsigned integers that may be associated with an IP prefix.
| >
| >However, the receiver need only use the first.
| >
| >       An implementation may consider only one of the encoded
| >tags, in which
| >       case the first encoded tag must be considered.  A tag
| >value of zero
| >       is reserved and should be treated as "no tag".
| >
| >IMHO, allowing an arbitrary number of tags affords more
| >potential for interoperability and deviant applications than
| >the 64 bit tag.
| >
| >
| >
| >
| >
| >Acee Lindem wrote:
| >> As a member of the routing area directorate, I have reviewed the
| >> subject document. Here are my comments:
| >>
| >> Comments:
| >>
| >>   1. The last sentence of the abstract doesn't make sense.
| >"Additionally,
| >>      the information can be placed in LSPs that have TLVs as yet
| >>      undefined, if this information is used to convey the same
| >>      meaning in these future TLVs as it used in the currently defined
| >>      TLVs". Suggested - "The administrative tag sub-TLVs may
| >be used with
| >>      with future TLVs as long as their semantics are preserved."
| >>
| >>   2. Section 5.2 - The value of the type is wrong - it
| >should be 2 rather
| >>      than 1.
| >>
| >>   3. Section 6 says the ordering of tags is not significant.
| >However, the
| >>      previous sections (5.1 and 5.2) say that an
| >implementation may only
| >>      consider the first tag.
| >>
| >>   4. Section 7 - List the requirements for receiving the new
| >Sub-TLVs in
| >>      this compliance section as well (even if they were stated
| >> previously).
| >>
| >>   5. Section 8 - The example talks about R2 associating tag 110 with
| >> property
| >>      A and prefix 1.1.1.0/24. Yet in Figure 1, prefix
| >1.1.1.0/24 with
| >> property
| >>      A is adjacent to R1 (which applies to me that R1 originate the
| >> prefix).
| >>      Please fix either the example or the figure.
| >>
| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt):
| >>
| >>   1. The abstract contains references. The documents should
| >be specified
| >>      by name since the abstract can be excerpted.
| >>
| >>   2. Line 323 over 72 chars.
| >>
| >>     Line 323 length is 74
| >>          Routing in IS-IS",
| >draft-ietf-isis-wg-multi-topology-03.txt,
| >> April
| >>
| >>   3. Pages 2, 3, 4, and 5 have over 58 lines.
| >>
| >
| >
| >--
| >Acee
| >

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 31 May 2003 00:29:03 +0200

acee,

our implementation currently support two tags
  and we pass it on in a ordered way for
  internal policy-processing e.g. first tag found is copied
  to the variable "tag" and the second tag is
  copied to the variable "tag2"; both variables can be 
  matched against in our internal policy processing
  language;

  and thats IMHO the only place
  where the draft needs to be more specific:
  how an implementation [order, etc.] maps IS-IS-tags
  to match-clauses in the local policy processor; 

i am unsure about the ordering and number of supported tags
of other implementations;
  stefano, can you shed some light ?

---

SHOULD is IMO a bit too strong wording, i'd be happy
with something like "MAY have more than one tag"

/hannes

On Thu, May 29, 2003 at 05:21:00PM -0400, Acee Lindem wrote:
| Hannes,
| 
| If we agree that having a single 32 bit and/or 64 bit tag is a
| good idea then perhaps we could change the wording of the draft to
| say that an implementation SHOULD only send and interpret a single
| tag and SHOULD ignore data past the first tag. This would allow
| the usage of multiple tags to be gracefully deprecated.
| 
| If this isn't acceptable then can we can agree on a small
| finite/known number of tags with suggested usage?
| 
| Thanks,
| Acee
| 
| Hannes Gredler wrote:
| >pls, keep in mind that there is already code in production that allows
| >more than one tag;
| >
| >common use i have seen so far is
| >
| >tag #1 controls L2L1 leakage
| >tag #2 for informational purposes and points to the area of origin;
| >
| >/hannes
| >
| >On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote:
| >| RE: Comments on <draft-ietf-isis-admin-tages-01.txt>
| >| 
| >| Acee,
| >| 
| >| As the original goal was to create a capability similar to OSPF's route 
| >tag,
| >| it may be wise to drop this capability.  On the otherhand, having 
| >multiple
| >| tags per route can provide more information about the route than a single
| >| tag.  In this regard, the 32 bit tag operates more like a community, and 
| >the
| >| 64 bit tag operates like an extended community.  From an implementation
| >| perspective, the same routines for matching and setting these fields 
| >should
| >| be similar to the community fields in BGP.
| >| 
| >| I would like to solicit the WG for comments on which capability is most
| >| attractive.  The goal is not to introduce too much bloat (is it too late 
| >for
| >| that?!) while still providing some flexibility.
| >| 
| >| As soon as I receive any final comments, I will release the updated 
| >draft.
| >| 
| >| Thanks for pointing out this critical piece!
| >| 
| >| Regards,
| >| chris
| >| 
| >| >-----Original Message-----
| >| >From: Acee Lindem [mailto:[email-masked]]
| >| >Sent: Friday, May 23, 2003 1:50 PM
| >| >To: Acee Lindem
| >| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area
| >| >Directorate
| >| >Subject: Re: Comments on <draft-ietf-isis-admin-tages-01.txt>
| >| >
| >| >
| >| >Christian, Stefano, Brad,
| >| >
| >| >The follow-up discussion on the necessity for both 32 bit and
| >| >64 bit tags raises the question as to whether or not it is
| >| >wise to allow an arbitrary number of tags to be advertised.
| >| >
| >| >       This draft proposes 2 new "Administrative Tag" sub-TLVs
| >| >to be added
| >| >       to TLV 135 and 235.  These TLVs specify one or more
| >| >ordered, 32 or 64
| >| >                                                  ~~~~~~~~~~~~~~~
| >| >       bit unsigned integers that may be associated with an IP prefix.
| >| >
| >| >However, the receiver need only use the first.
| >| >
| >| >       An implementation may consider only one of the encoded
| >| >tags, in which
| >| >       case the first encoded tag must be considered.  A tag
| >| >value of zero
| >| >       is reserved and should be treated as "no tag".
| >| >
| >| >IMHO, allowing an arbitrary number of tags affords more
| >| >potential for interoperability and deviant applications than
| >| >the 64 bit tag.
| >| >
| >| >
| >| >
| >| >
| >| >
| >| >Acee Lindem wrote:
| >| >> As a member of the routing area directorate, I have reviewed the
| >| >> subject document. Here are my comments:
| >| >>
| >| >> Comments:
| >| >>
| >| >>   1. The last sentence of the abstract doesn't make sense.
| >| >"Additionally,
| >| >>      the information can be placed in LSPs that have TLVs as yet
| >| >>      undefined, if this information is used to convey the same
| >| >>      meaning in these future TLVs as it used in the currently defined
| >| >>      TLVs". Suggested - "The administrative tag sub-TLVs may
| >| >be used with
| >| >>      with future TLVs as long as their semantics are preserved."
| >| >>
| >| >>   2. Section 5.2 - The value of the type is wrong - it
| >| >should be 2 rather
| >| >>      than 1.
| >| >>
| >| >>   3. Section 6 says the ordering of tags is not significant.
| >| >However, the
| >| >>      previous sections (5.1 and 5.2) say that an
| >| >implementation may only
| >| >>      consider the first tag.
| >| >>
| >| >>   4. Section 7 - List the requirements for receiving the new
| >| >Sub-TLVs in
| >| >>      this compliance section as well (even if they were stated
| >| >> previously).
| >| >>
| >| >>   5. Section 8 - The example talks about R2 associating tag 110 with
| >| >> property
| >| >>      A and prefix 1.1.1.0/24. Yet in Figure 1, prefix
| >| >1.1.1.0/24 with
| >| >> property
| >| >>      A is adjacent to R1 (which applies to me that R1 originate the
| >| >> prefix).
| >| >>      Please fix either the example or the figure.
| >| >>
| >| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt):
| >| >>
| >| >>   1. The abstract contains references. The documents should
| >| >be specified
| >| >>      by name since the abstract can be excerpted.
| >| >>
| >| >>   2. Line 323 over 72 chars.
| >| >>
| >| >>     Line 323 length is 74
| >| >>          Routing in IS-IS",
| >| >draft-ietf-isis-wg-multi-topology-03.txt,
| >| >> April
| >| >>
| >| >>   3. Pages 2, 3, 4, and 5 have over 58 lines.
| >| >>
| >| >
| >| >
| >| >--
| >| >Acee
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: stefano previdi <[email-masked]>
Date: Sat, 31 May 2003 12:00:37 +0200

>  stefano, can you shed some light ?

I have no specific requirement on this matter... as long as 
an applicatin is considered compliant when handling the first 
encountered tag.

s.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 29 May 2003 17:21:00 -0400

Hannes,

If we agree that having a single 32 bit and/or 64 bit tag is a
good idea then perhaps we could change the wording of the draft to
say that an implementation SHOULD only send and interpret a single
tag and SHOULD ignore data past the first tag. This would allow
the usage of multiple tags to be gracefully deprecated.

If this isn't acceptable then can we can agree on a small
finite/known number of tags with suggested usage?

Thanks,
Acee

-- 
Acee