Subject: [Isis-wg] AD-review of draft-ietf-isis-admin-tags-01

From: Alex Zinin <[email-masked]>
Date: Mon, 5 May 2003 17:34:10 -0700

Folks-

 I reviewed the draft and had an opportunity to discuss my comments
 with the authors and the WG chairs. Below is the summary. I also
 include comments from the rtg-dir--thanks, Acee.

 Meta: Why do we need two tag TLVs?

    This is still an open question for me.
 
    Clearly, one 32-bit tag is enough to control prefix distribution
    throughout the domain. Two tags complicate both the specification
    and operation of the network, as we have to deal with some
    "interesting" questions, like whether the implementations should
    be able act upon (filter prefixes based on) just one TLV or both,
    and whether the two TLVs operate on the same (64-bit) value space
    (with one covering only 1/2) or on separate ones, and how they
    should work together.

    So, I studied the ML archives looking for clue and I found that the
    main motivation for the 64-bit tag appears to be transporting of
    Extended Communities for a certain case of 2547 deployment. If
    that's the case, than it seems that a better approach would be to
    specify the 64-bit TLV as a "BGP <attribute>" or "VPN <attribute>"
    and be honest about it's functionality than to have two tags.

    I'd love to hear more on this topic.

 We had an agreement on the rest of the issues below.

 1. Discourage incompatible intra-area SPF modifications
 
    There is a case where one could potentially use a tag value to
    decide to not install a prefix in the routing table during
    intra-area RT calculation and get into loops or blackholes. Some
    words should be put in the text saying that implementations should
    not use tags to change their intra-area routing calculation in a way
    that would make it inconsistent with ISO 10589.

 2. Require compliant implementations to support prefix filtering at
    area borders

    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.

 3. Processing of multiple instances of the TLV.

    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. We need consistency in behavior.
    
    The proposal was to put text saying that only the first copy of
    the TLV must be considered.

 4. Tag ordering clarifications

    Text in section 6 needs to be clarified to make it explicit that
    [re]ordering of tags makes sense only when L1/L2 route leaking is
    performed.

 5. IANA considerations

    Change the text to say "This document defines..."

 6. Comments from rtg-dir:

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

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.

Nits from Acee:

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

Thanks!
--
Alex Zinin

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

---

From: stefano previdi <[email-masked]>
Date: Thu, 8 May 2003 17:35:49 +0200

>     I'd love to hear more on this topic.

me too. I tend to agree with you about using a separate (sub)TLV.

>     that would make it inconsistent with ISO 10589.

I naively thought it was implicit that routing calculation 
should be consistent....

>     Putting in 'MUST support filtering at the area boundaries' would

ok.
 
>     the TLV must be considered.

ok
 
>     [re]ordering of tags makes sense only when L1/L2 route leaking is

L1/L2 and L2/L1

s.

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 10 May 2003 01:16:18 +0200

On Mon, May 05, 2003 at 05:34:10PM -0700, Alex Zinin wrote:
| Folks-
| 
|  I reviewed the draft and had an opportunity to discuss my comments
|  with the authors and the WG chairs. Below is the summary. I also
|  include comments from the rtg-dir--thanks, Acee.
| 
|  Meta: Why do we need two tag TLVs?
| 
|     This is still an open question for me.
|  
|     Clearly, one 32-bit tag is enough to control prefix distribution
|     throughout the domain. Two tags complicate both the specification
|     and operation of the network, as we have to deal with some
|     "interesting" questions, like whether the implementations should
|     be able act upon (filter prefixes based on) just one TLV or both,
|     and whether the two TLVs operate on the same (64-bit) value space
|     (with one covering only 1/2) or on separate ones, and how they
|     should work together.

the basic idea was that today most SPs do run VPN environments and
today there are well established tagging schemes;
typically those tag-spaces are based on extd. BGP communties
which are 64-bits in size;

so the question from an administration point of view is wether it
makes sense to create another 32 bit tag-space or to let implementations
allow to map those tags 1:1 to IS-IS admin tags;

i do agree that there should be a section in the draft that should
cover 32-bit / 64-bit tag interaction;

/hannes

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 May 2003 16:38:16 -0700

Hannes,

> which are 64-bits in size;

if this is the case, then how about this:

    it seems that a better approach would be to
    specify the 64-bit TLV as a "BGP <attribute>" or "VPN <attribute>"
    and be honest about it's functionality than to have two tags.

Thanks.
Alex

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 12 May 2003 17:59:59 +0200

On Fri, May 09, 2003 at 04:38:16PM -0700, Alex Zinin wrote:
| Hannes,
| 
| > the basic idea was that today most SPs do run VPN environments and
| > today there are well established tagging schemes;
| > typically those tag-spaces are based on extd. BGP communties
| > which are 64-bits in size;
| 
| if this is the case, then how about this:
| 
|     it seems that a better approach would be to
|     specify the 64-bit TLV as a "BGP <attribute>" or "VPN <attribute>"
|     and be honest about it's functionality than to have two tags.

IMO tag-32 is not explicit about its purpose, either;
i.e. could be a tag that controls L2L1 leaking but could be also
a tag which controls origin related information for better troubleshooting
information; the function of the tag-32 has deliberlatly been left open:
why is there a need to be that firm about the usage of a 64-bit tag ?

i don't see the benefit of having several different 64-bit tags - some
clarification in the draft describing some sample applications for
a general 64-bit tag ought to be enough;

/hannes

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 12 May 2003 21:54:17 +0200

>a general 64-bit tag ought to be enough;
agreed, the draft gains nothing by specifying that the 64-bit MUST be 
used for VPN purposes.
It may very well later be used for other things. As an _example_ though, 
the VPN application would be fine.

    -- tony