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

From: Acee Lindem <[email-masked]>
Date: Sat, 15 Mar 2003 21:37:22 -0500

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: Alex Zinin <[email-masked]>
Date: Sat, 29 Mar 2003 22:05:05 -0800

I noticed that the WG chairs have not been CC'ed on this one.
I'll be reviewing this draft early next week.

Thanks, Acee.
-- 
Alex

---

From: Alex Zinin <[email-masked]>
Date: Wed, 16 Apr 2003 11:33:51 -0700

Guys,

 Below's the list of my thoughts in addition to the comments
 Acee brought.

 Regards.

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

Comments:

In order to preserve interoperability with tag-unaware routers, I
think we should add some words saying that the implementations MUST
NOT change their SPF calculation based on the contents of the
introduced TLVs.

Thinking aloud: though the mechanism is inherently opaque, if we want
the implementations claiming their compliance to it to really be
usable for [from the doc] "controlling redistribution between levels
and areas, different routing protocols", should we say that compliant
implementations SHOULD support such filtering? On the one hand,
there's a wide spectrum of applications that can use these tags and we
don't want to say foo and bar are the only ones, on the other hand if
I were deploying this in a multi-vendor environment, I'd likely want
to see a consistent minimal set of features, i.e., not just attaching
a tag, but also executing on it if the router is a L1/L2 or an ASBR.
Did you guys think about this?

What I think is missing in the draft is specification of how multiple
instances of the same sub-TLV should be treated, i.e., I could see
some implementations deciding to merge the tag sets, and some using
just the first (or the last) instance, which would result in interop
issues. Should be spelled out, I think.

A similar, and somewhat more interesting question is about the two
types of tags--32 bits and 64 bits. Since the value spaces for the two
are overlapping, i.e., there's a range {x}, where X can be coded as
both 32 and 64 bits, should the implementations consider the two TLVs
as operating on a single large 64-bit space (with one covering only
half the space, and one covering the whole thing), or on two separate
ones with different sizes. In other words, if my policy says "match
tag 234", should it match both a 32- and a 64-bit tag, or should it
differentiate between the two and operate more in a way of "match
tag-32 234" and "match tag-64 234"? I could see how different
implementations could treat this differently and I could get different
route filtering results given the same input data.

There will also be a question in the IESG on why do we need a 32-bit
tag if we have a 64-bit one, which could accommodate 32-bit values
too. Do we have an answer besides "some folks believed 32 bits is
enough in most cases, but other folks had a case where 64 bits would
be more convenient"?

> 6. Ordering of Tags
> 
>    The semantics of the tag order are implementation-dependent.  That
>    is, there is no implied meaning to the ordering of the tags that
>    indicates a certain operation or set of operations need be performed,
>    based on the order of the tags.  Each tag SHOULD be treated as an
>    autonomous identifier that MAY be used in policy to perform a policy
>    action.  Whether or not tag A preceeds or succeeds tag B SHOULD not
>    change the meaning of the tag set.  However, an implementation MAY
>    wish to preserve tag ordering such that an ordered set of tags has
>    meaning to the local policy.

To preserve tag ordering where? Within the TLV? (a pseudo-question
really, since one shouldn't change someone else's TLV contents)

> 7. A compliant IS-IS implementation:

>    MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or
>    235.

There will be a question on whether attaching both TLV types MUST be
supported by an implementation, or just one of them. I think we need
to say both.

> 10. IANA Considerations
> 
>    The authors have chosen "1" as the typecode of the 32-bit
>    Administrative Tag sub-TLV and "2" as the typecode of the 64-bt
>    Administrative Tag SubTLV.  These values must be allocated by IANA.

Change to "This document defines..."?

Nits below:

> 1. Status of this Memo

Shouldn't be numbered

> 2. Abstract

The rfc-ed will not like the references in the abstract,
please remove.

> 5.1. 32-bit Administrative Tag Sub-TLV 1
> 
>    The Administrative Tag shall be encoded as one or more 4 octet
>    unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The
>    Administrative Tag Sub-TLV has following structure:
> 
>         1 octet of type (value: 1)
>         1 octet of length (value: multiple of 4)
>         one or more instances of 4 octets of administrative tag

Would be great if we had the same format as in RFC1195, or 3373
for consistency. Using IETF format is an option too.

Ditto for 5.2

> 12. References

Please split them to normative and informative like below:

12. Normative References

   [1] "Intermediate System to Intermediate System Intra-Domain Routeing
       Exchange Protocol for use in Conjunction with the Protocol for
       Providing the Connectionless-mode Network Service (ISO 8473)",
       ISO 10589.

   [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and
       dual environments", RFC 1195, December 1990.

   [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering",
       Internet Draft, "Work in Progress", September 2000.

   [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution
       with Two-Level IS-IS" RFC 2966, October 2000

13. Informative References

   [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus,
       J., "Requirements for Traffic Engineering Over MPLS," RFC 2702,
       September 1999.

   [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology
       Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April
       2002.

---

From: stefano previdi <[email-masked]>
Date: Thu, 17 Apr 2003 15:26:13 +0200

Hi Alex,

thanks for your comments... see mine below... and sorry for 
the delay.

>  Below's the list of my thoughts in addition to the comments

I disagree mainly because the two things (tags and SPF 
computation) are not related. You _may_ want to give to SPF 
some indications about tagged prefixes, but this is a local 
matter and your routing tables should be consistent across 
the network (and you don't need a draft telling you this).
Specifying that you "MUST NOT" do this or that, is outside of 
the scope of this draft.
 
> implementations SHOULD support such filtering? 

no. it's just a feature that could hlep (and not even in all 
cases).

> On the one hand,

yes, and again I don't believe it's the role of the draft to 
tell you what to do with this subTLV. The draft just 
specifies the data. What you do with this data is a matter of 
applications that are well outside the scope of the draft.

> issues. Should be spelled out, I think.

yes, you can give some hints. At the origin we said that in 
case of multiple tags and a router supporting only one, then 
you should take the first. I know at least one major 
implementation that does this...;-)
 
> types of tags--32 bits and 64 bits. 

don't tell me this...;-)

> Since the value spaces for the two
> tag-32 234" and "match tag-64 234"? 

it's a local matter... I believe. Also, I believe the 
implementation should not have a command like "match tag" but 
rather I prefer to see "match tag-32" or "match tag-64".

If you want to cover the case where only "match tag" is 
available, then you enter the complicated world of default 
interpretation of values... I don't really like this...

> I could see how different
> too. 

because we already have an implementation using 32 bits and 
sincerely I did never understand the need of 64 bits... 

> Do we have an answer besides "some folks believed 32 bits is

the answer is "we _had_ 32 bits and someone said that 64 is 
needed"... I'm waiting for thew next one asking me 128 bits...

> really, since one shouldn't change someone else's TLV contents)

except when you do route-leaking. You may receive a  set of 
tags in one level and change them for the other level. Please,
don't ask me a real case scenario for this...;-)

> supported by an implementation, or just one of them. I think we need

I don't think so. the subTLV is optional anyway.
 
> Change to "This document defines..."?

I'll let the original author to fix the editorial issues. 
Brad, Christian ?

s.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 2 May 2003 02:20:36 -0400

Stefano,

Sorry for a long delay. I had an opportunity to discuss the comments
brought up below with Tony P. We agreed on many points which I will
summarize below, except that the need for two tags is still unclear to
me, and I need someone to talk about this. See below for more details,
pls. Once we have some sort of agreement, I'll post my comments to the
WG list, so the process is open.

> Specifying that you "MUST NOT" do this or that, is outside of 

There is a case where one could potentially use a tag value to decide
to not install a prefix in the routing table and get into loops. On
the one hand, I agree with Mike's opinion he expressed in his message
to the list on the auto-encaps draft, that we can't possibly specify
all wrong things that could be but should not be done, on the other,
the nature of the tag is quite opaque and sort of encourages
creativity ;) and discouraging intra-area SPF filtering could be
useful. However, since I can argue both ways myself, I will leave
this up to you.

> applications that are well outside the scope of the draft.

The draft definitely reads like filtering at the area boundaries is
one of the major applications of this TLV. However, because the
document requests the compliant implementations to only be able to
insert the tag, but not filter using it at the L1/L2 IS'es, an
operator cannot expect all compliant implementations to be useful for
this function, i.e., they will need to ask if functions outside the
scope of this document are supported by specific vendors, go into
details of how they do that to make sure different implementations can
work together in a consistent way. Putting in 'MUST support filtering
at the area boundaries' would solve this.

> implementation that does this...;-)

Let's put text in the draft saying that only the first copy of
the TLV must be considered. We need consistency in behavior.

...

> don't tell me this...;-)
...

> sincerely I did never understand the need of 64 bits... 

Does any of the co-authors know the reason?

> don't ask me a real case scenario for this...;-)

That's fine. It's just that the text didn't explicitly say
it was the case of route leaking between levels. Some word
tweaking should help.

Alex

---

From: stefano previdi <[email-masked]>
Date: Fri, 2 May 2003 10:16:28 +0200

Alex,

On Friday 02 May 2003 08:20, Alex Zinin wrote:
> me, 

to me too...

> and I need someone to talk about this. See below for more details,

I can tell you that there is already an implemented 
aplication that changes the way SPF installs prefixes in rib 
according to tagged prefixes...

Also, I still do not believe drafts should be so restrictive 
in things that are not related to what they describe.

> one of the major applications of this TLV. 

just one... I can tell you that from our side I don't see 
filtering beeing deployed very soon (mostly because there 
are no levels) however, I can see need for another tag 
application (the one I mentionned above).

> However, because the

well, what if a vendor doesn't want to implement filtering 
(because no customer ever asked for it) but he wants to 
implement the spf/rib modification ? Again, I don't believe 
filtering is the first/major application of tags that will 
be deployed.

but I'm not reluctant to put "MUST" if you believe it's 
necessary (it's anyway in my code, ... ) it's just that I 
don't believe it is.

> Does any of the co-authors know the reason?

no, the only one who can help you is Hannes Gredler 
([email-masked]) who made the request. I believe the 
request came from some obscure reasons related to mpls-vpn 
extended community attribute (64 bits) that could be 
propagated through the igp... have no clue about the scenario 
that would require such a thing...

> it was the case of route leaking between levels. Some word

well, I believe it falls under "filtering prefix propagation 
between levels" since the same issue happen in both ways 
(l1->l2, l2->l1).

s.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 2 May 2003 12:12:11 -0400

Stefano,

> according to tagged prefixes...

Hmmm... seems that my thoughts were not just out of the blue ;)

can you describe what the application is and how it is compatible with
standard ISIS implementations?

...

> necessary (it's anyway in my code, ... ) it's just that I 

Yes, I think we should put a requirement for this.

> that would require such a thing...

OK, seems that this is best taken to the list.

> between levels" since the same issue happen in both ways 
(l1->>l2, l2->l1).

Right, it's just that the doc could be more clear about this.

Alex

---

From: stefano previdi <[email-masked]>
Date: Fri, 2 May 2003 18:22:09 +0200

Alex,

> standard ISIS implementations?

spf computation and rib installation are not part of any 
protocol standardisation (I believe). The only requirement is 
that route computation should be consistent all along the 
area/network.

routing computation has been already modified in different 
ways (incremental-spf is one of them and prc is another one).

without revealing secrets I can tell you that there are ways 
to improve routing convergence for some prefixes... if you 
know which prefixes you want to converge faster... and tags 
is one mechanism to use.

s.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 2 May 2003 12:28:39 -0400

Stefano,

> protocol standardisation (I believe).

Yes and no.

Clearly if different routers choose different SPTs they won't
be able to work with each other. So, the basic algo is needed
to be standard, the exact implementations of it, or optimizations
like incremental SPF, etc. are definitely not.

> The only requirement is 

Plus compatible with existing STD implementations.

> know which prefixes you want to converge faster... and tags 

If it produces the same set of routes as the standard SPF,
we're fine.

Alex

---

From: stefano previdi <[email-masked]>
Date: Fri, 2 May 2003 18:37:20 +0200

On Friday 02 May 2003 18:28, Alex Zinin wrote:
> be able to work with each other. 

by definition SPT are never equal... they are just consistent 
each others... but I believe it's what you itended as well.

> So, the basic algo is needed

theoretically speaking I don't agree... practically speaking 
I do.

> Plus compatible with existing STD implementations.

I don't understand "compatible". For me only consistency 
matters.
 
> If it produces the same set of routes as the standard SPF,

yes, and of course it does... otherwise my nights would be 
very short ...;-)

s.

---

From: mike shand <[email-masked]>
Date: Fri, 02 May 2003 18:37:36 +0100

Just a point here. You may or may not agree with their "wisdom", but ISO 
didn't standardize the SPF in ISO/IEC 10589, they put it in an 
informational appendix, and said

"Any implementation of an SPF algorithm meeting both the
static and dynamic conformance requirements of clause 12 of
this International Standard may be used. Recommended implementations
are described in detail in annex C."

         Mike

---

From: Alex Zinin <[email-masked]>
Date: Fri, 2 May 2003 14:56:56 -0400

Mike,

 I think we're in agreement. See my message to Stefano.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 2 May 2003 14:56:11 -0400

Stefano,

> each others... but I believe it's what you itended as well.

Right, as long as routers use the _shortest_ paths to calculate route
metrics _and_ install the same set of routes within an area, they will
work together fine, i.e., SPTs are consistent because of the
"shortest" word. One could even use centralized Bellman-Ford to
calculate shortest paths, it's just that it's computationally much
worse than Dijkstra. Anyways, we're playing words here, while we both
understand what the matter is ;)

> theoretically speaking I don't agree... practically speaking 

I guess a refinement that should satisfy everyone should be to say
that as long as implementations come up with the same results as the
algorithm described in the spec, they are good.

> I don't understand "compatible". For me only consistency 

by compatible I mean able to work correctly (without loops and
blackholes) with existing implementations present in the network,
so it is indeed consistency, I guess.

> yes, and of course it does... otherwise my nights would be 

I would be surprised if you said otherwise! :)

So maybe we should put in the text some words saying that
implementations should not use tags to change their routing table
calculation in a way that would affect interoperability with
preexisting implementations, or something like this.

Alex

---

From: Acee Lindem <[email-masked]>
Date: Fri, 23 May 2003 13:49:46 -0400

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

---

From: stefano previdi <[email-masked]>
Date: Fri, 23 May 2003 21:43:13 +0200

>        to TLV 135 and 235.  These TLVs specify one or more ordered, 32 or 64

is your suggestion to allow a single 32bits tag and use a 
separate TLV for the extComm-tag (4bits) ? If yes, I 
subscribe to it.

s.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 23 May 2003 16:07:56 -0400

> separate TLV for the extComm-tag (4bits) ? If yes, I 

Yes - that would be great. I feel more strongly about limiting
the number of tags than the usage of the 64 bit tag.

Thanks,
Acee

>>>     this compliance section as well (even if they were stated 
>>
> previously).
> 
>>>         Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, 
>>
> April
> 

-- 
Acee