Subject: RE: Comments on <draft-ietf-isis-admin-tages-01.txt>

From: "Martin, Christian" <[email-masked]>
Date: Fri, 23 May 2003 15:20:41 -0400

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
>

---

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

---

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

---

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

---

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.

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

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 01 Jun 2003 12:03:06 +0200

> finite/known number of tags with suggested usage? 

So, I watched for a while Alex and now Acee trying to influence the
direction of this thing (after a last call funny enough) and I definitely
do _NOT_ like the direction this is going.  I have an understanding for
'exact specification' and 'understanding what the tags are doing' and
'we don't want 64 and 32 bits in place' __BUT__

1) Slashing the whole thing to things like 1 tag  only and squeezing it
    in size may feel good in terms of specification but it will probably
make
    it as flexible and useful as the OSPF tag, namely completely useless.
    Just look at the unnatural contortions of RFC 1994.
2) I am lacking to follow the arguments here why multiple tags are so
harmfull,
    why we have to know _exactly_ what every tag means and why the
    32 and 64 bit tags together are such a big issue. The only ones
    I saw were basically 'it may blackhole routes or lead to problems
    when misconfiguration or implementaion errors occur'. Well, guess
    what, that's true for almost any RFC that ends up implenented in
    a screwy way. ISIS is a small implementor's community and we do
    not have to build specs in a way that every kid hacking Linux can
    implement it perfectly without having written a protocol in their life
    before.

Therefore, I would encourage the implementors to think whether they want
to end up in an OSPF-like tag corset or they want to preserve the
flexibility of having multiple tags that can be used in a global or
local fashion
(global shall necessitate a description for interop-purposes, probaby
2547 extcomm being carried around would be such a thing) or otheriwse
for all kind of nice local/proprietary things. BGP extscomms are already
used in such way couple of nice & smart ways (I won't go into d3etails
to protect the usually suspect vendors ;-) Some of those mechanisms
could be used for ISIS to e.g. accelerate convergence on routers
supporting these extensions.  So, if implementors feel strongly here,
please push back on all that 'we'll make it soo much nicer' tweaking and
let's try to get this draft out in some decent time rather than the usual
3-infinity years it takes an ISIS RFC to be issued.

I would strongly encourage keeping multiple, ordered tags and the draft
not touching on their application. I would also encourage a 32 and a
64 bit tag, both being independent address spaces. It's not ideal but
what's the point redoing stuff in the field just so the encoding is tad
nicer? I would encourage a draft on how the 2547 stuff is being sloshed
around using tags. And I think we added a paragraph that when the
route selection supresses a route based on a tag we may end up with
 a blackhole.
  
    thanks
   
    -- tony

>> | | Acee,
>> | | As the original goal was to create a capability similar to OSPF's
>> route tag,
>> | | I would like to solicit the WG for comments on which capability
>> is most
>> | | 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: Tony Przygienda <[email-masked]>
Date: Sun, 01 Jun 2003 12:20:18 +0200

>
>
>I would strongly encourage keeping multiple, ordered tags
>
oops, glas of wine here, it's   'not-ordered'  ...

    -- tony

---

From: Acee Lindem <[email-masked]>
Date: Sun, 01 Jun 2003 07:28:53 -0400

> route selection supresses a route based on a tag we may end up with

So if we step back, what we have here is a pair of generic TLVs (32
and 64 bits tags) which can be used to send an arbitrary amount of
opaque information. Will the tag encodings and their respective
applications be described in future drafts?

Thanks,
-- 
Acee

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 01 Jun 2003 13:55:58 +0200

> opaque information. 

yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred
bytes per prefix if you really want to but then, I assume to fix this
problem in OSPF
you will decleare RFC2370 unlawfull really soon?
If the 'hidden communication channel' is the problem you
try to solve, security groups will yield a much more fruitfull harvest.

> Will the tag encodings and their respective

That would be very, very desirable but given e.g. EXTCOMMs realities,
may only partially come to fruition. I would expect that stuff that has to
interoperate would be documented, stuff that does not (e.g. an extension
that improves protocol behavior if the other receipient understands it,
otherwise yields nothing) not necessarily. Again, RFC2370 comes to mind.

    thanks

    - tony

---

From: Acee Lindem <[email-masked]>
Date: Sun, 01 Jun 2003 09:34:21 -0400

> you will decleare RFC2370 unlawfull really soon?

Actually, to the best of my knowledge, most of the opaque LSA applications
are documented in RFCs and/or drafts (although I know there are undocumented
TLVs sent within TE LSAs).

-- 
Acee

---

From: Alex Zinin <[email-masked]>
Date: Mon, 2 Jun 2003 18:24:53 -0700

Hannes,

  Are the tag and tag2 both 32-bit tags taken from the same TLV or do
  you have the 64-bit tags coded/deployed also?

-- 
Alex
http://www.psg.com/~zinin/

> | finite/known number of tags with suggested usage?
| >>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

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 4 Jun 2003 10:47:20 +0200

On Mon, Jun 02, 2003 at 06:24:53PM -0700, Alex Zinin wrote:
| Hannes,
| 
|   Are the tag and tag2 both 32-bit tags taken from the same TLV or do
|   you have the 64-bit tags coded/deployed also?

the code that is currently in the field does support only 32-bit tags; both tags
are attached either to TLV 135 and 236 [pls have a look at the attached tcpdump
output];

/hannes

#tcpdump -nvr subtlv2.tcpdump
19:14:07.936565 OSI, IS-IS, length: 201
        hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0), pdu-type: L1 LSP
          lsp-id: 0000.0000.0003-00, seq: 0x0000004f, lifetime: 65533s
          chksum: 0x23cb (correct), PDU length: 201, L1L2 IS
            Area address(es) TLV #1, length: 12
              Area address (length: 1): 01
              Area address (length: 5): 47.0002.0001
              Area address (length: 3): 49.0001
            Protocols supported TLV #129, length: 2
              NLPID(s): IPv4, IPv6
            Traffic Engineering Router ID TLV #134, length: 4
              Traffic Engineering Router ID: 192.168.1.3
            IPv4 Interface address(es) TLV #132, length: 4
              IPv4 interface address: 192.168.1.3
            Hostname TLV #137, length: 7
              Hostname: speed-1
            Extended IS Reachability TLV #22, length: 17
              IS Neighbor: 0000.0000.0003.02, Metric: 10, sub-TLVs present (6)
                IPv4 interface address: 192.168.1.1
            Extended IPv4 reachability TLV #135, length: 79
              IPv4 prefix:     192.168.1.0/24, Distribution: up, Metric: 10, sub-TLVs present (10)
                32-Bit Administrative tag: 0x00001267 (=4711)
                32-Bit Administrative tag: 0x0000c000 (=49152)
              IPv4 prefix: 192.168.223.224/28, Distribution: up, Metric: 10, sub-TLVs present (10)
                32-Bit Administrative tag: 0x00001267 (=4711)
                32-Bit Administrative tag: 0x0000c000 (=49152)
              IPv4 prefix:        10.0.0.4/30, Distribution: up, Metric: 10, sub-TLVs present (10)
                32-Bit Administrative tag: 0x00001267 (=4711)
                32-Bit Administrative tag: 0x0000c000 (=49152)
              IPv4 prefix:     192.168.1.3/32, Distribution: up, Metric: 0, sub-TLVs present (10)
                32-Bit Administrative tag: 0x00001267 (=4711)
                32-Bit Administrative tag: 0x0000c000 (=49152)
            IPv6 reachability TLV #236, length: 33
              IPv6 prefix: 2001:600::3/128, Distribution: up, Metric: 0, Internal, sub-TLVs present (10)
                32-Bit Administrative tag: 0x00001267 (=4711)
                32-Bit Administrative tag: 0x0000c000 (=49152)