Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt

[Les Ginsberg <[e-mail]>]

At 08:13 AM 7/2/2003 +0200, stefano previdi wrote:
>On Wednesday 02 July 2003 08:07, Hannes Gredler wrote:
> > On Wed, Jul 02, 2003 at 01:41:22AM -0400, Jeff Learman wrote:
> > |
> > | I think we want to know what a router IS DOING.  We should
> > | rely on product documentation to find out what it is capable of
> > | being configured to do and how to do so.  Or is this the "marketing
> > | protocol" ;)
> >
> > well if this would be the "marketing proto" then we would need probably
> > to dedicate a few fragments ...
> >
> > wrt what the router IS doing ? - i still got no answer
> > to my original question:
> >
> > what information does the capability vector as-is provide that cannot
> > be gathered from the TLV list of the LSP? [beside link-local
> > things like ptp-IIH over LANs, graceful restart etc.]
>
>I agree. Note that the capabilities draft has been originally
>written for propagating Traffic Engineering capabilities that
>couldn't be inferred from the existance (or absence) of TE
>sub TLV. The first capability defined was the PCS (Path
>Computation Server) which tells that the box is capable to
>compute path across area/domain boundaries (or something
>similar to that, sorry I'm not a TE expert).
>
>Then, for reasnos I don't know, we added other capabilities
>bits&flags but not sure it makes a lot of sense.
>
>s.


I also agree with Hannes/Stefano. Where the capabilities are clearly 
visible from TLVs sent by the originating system, putting a bit for them in 
the capabilities flag field simply raises the bizarre possibility that a 
system could advertise that it supports something but not send the matching 
TLVs. Which one do you believe? Who needs this problem?

So, if we look at the current proposed list:

   0-3           Reserved

For what (BTW)???

    4             IS-IS graceful restart capable [4]

Not needed. Restart TLV must always be included in IIHs if the capability 
is supported

    5             IS-IS and BGP blackhole avoidance capable [6]

OK

    6             IS-IS wide metric processing capable [3]
    7             IS-IS short metric processing capable [1]

For these two, the capability is not needed since you can deduce that from 
the TLVs present, but you cannot always know what metrics are currently 
being used in the SPF. For example, the transition strategy suggested in 
draft-ietf-isis-ip-interoperable (Section 8.1) defines periods where a TLV 
may be sent but not used in the SPF. So these could more usefully be 
defined to indicate what is currently being used in the local system's SPF. 
Given that the capabilities TLV is meant to be leaked into other levels, 
this creates a problem in that the usage can differ for the same router at 
Level 1 and Level 2. I suppose this could be solved by adding two more bits 
and making the bits level specific.

    8             IS-IS hmac-md5 authentication capable [5]

Not needed.

    9             IS-IS Traffic Engineering support [3]

Not needed.

    10            IS-IS point-to-point over LAN [7]

??? Maybe this is useful...but if one side supports this and another 
doesn't the adjacency won't come up. I don't think this is very hard to 
debug on any system with useful event logging, but maybe...

    11            IS-IS Path Computation Server discovery [10]

OK

    12            M-ISIS capable [8]

Not needed.

    13            IS-IS IPv6 capable [9]

Not needed.


Some other comments:

1)The use of "router-id" to identify the source of this TLV may be OK - but 
it is a bit problematic as has been pointed by Nagi. It is conceivable that 
an implementation may support this draft but NOT support TE, in which case 
it might not have a Router ID. (Unlikely but conceivable.) More relevant to 
me is the fact that in other aspects of the protocol the source information 
is always identified by the systemID - here we seem to break that rule. But 
if we were to use systemID, we must be careful as well, because the fact 
that this TLV is to be leaked places additional requirements on the 
systemID i.e. that it be unique throughout the domain, which is a stronger 
requirement than ISO 10589 imposes. As a practical matter this may not be a 
significant issue, but would need to be explicitly stated.

2)Requiring the length field in a sub-TLV to be set to a multiple of 4 
seems very non-IS-IS-like.

3)Requiring the capability flag sub-TLV (code 1) to be present in each 
instance of this TLV seems like a bad idea. From what I have seen of 
proposals for use of sub-TLVs of this TLV, it seems quite likely that a 
system will have to send multiple TLVs to advertise all of the sub-TLV 
information. There seems no need to repeat the capabilities flag sub-TLV 
each time.

4)Why do we need 29 bits of "Reserved Information Flag"?? This seems like 
an attempt to 32 bit align the contents of the TLV - which is futile.

    Les


> >
> >
> > ---
> > also there may be some need to spend more bits as some of the features
> > being listed in the draft may have a asymmetric nature; i.e.
> > a router does not actively send a certain TLV but may be capable
> > of processing this TLV on receipt; ... sort/wide metric and the
> > completetely wild [i.e. very vendor has its own] transition methods
> > are a good example;
> >
> >
> > /hannes
> >
> > | Jeff
> > |
> > | At 01:30 AM 7/2/2003, Hannes Gredler wrote:
> > | >jeff,
> > | >
> > | >changed subject -
> > | >
> > | >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote:
> > | >|
> > | >| Presumably it's functions that are enabled.  A protocol doesn't
> > | >| need to say what a router could do if configured differently,
> > | >| just what it's prepared and able to do right now.
> > | >
> > | >hmmm don't agree - that brings us back to the question what
> > | >is the objective of the draft ? i read between the lines that
> > | >it was intended as quick view what the IS-IS SW can do and whats
> > | >enabled;
> > | >
> > | >the network administrator should have the choice to
> > | >
> > | >  a. upgrade the software or
> > | >  b. turn feature X on
> > | >
> > | >for doing that IMHO you need two subTLVs/bitvectors
> > | >
> > | >  1. one displaying the SW capabilities
> > | >  2. one displaying whats actually configured
> > | >
> > | >i agree that 2. is largely redundant becasue one can
> > | >look at the TLV list of a specific node to see what
> > | >is turned on;
> > | >
> > | >or in other words: what information does the
> > | >capability vector as-is provide that cannot
> > | >be gathered from the TLV list ? [beside link-local
> > | >things like ptp-IIH over LANs, graceful restart etc.]
> > | >
> > | >/hannes
> > | >
> > | >| I suppose that could be made clear in the text.
> > | >|
> > | >| At 02:00 PM 7/1/2003, Hannes Gredler wrote:
> > | >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote:
> > | >| >| folks,
> > | >| >|
> > | >| >| this draft is the isis part of the IGP capability, please review
> > | >| >| and comment, thanks.
> > | >| >|
> > | >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt
> > | >| >
> > | >| >naiming,
> > | >| >
> > | >| >when you talk about capabilities in the draft what is really meant ?
> > | >| >  actual capabilities or potential capabilies ?
> > | >| >
> > | >| >  when does a router has to set a bit ? - e.g. if capability X has
> > | >| >  been configured or there is in general support for capability X
> > | >| >  in the current loaded SW;
> > | >| >
> > | >| >/hannes
> > | >| >
> > | >| >---
> > | >| >
> > | >| >4.3 Reserved IS-IS Router Capability Bits
> > | >| >
> > | >| >   We have assigned some pre-determined bits to the first capability
> > | >| >   flag.
> > | >| >
> > | >| >   Bit           Capabilities
> > | >| >
> > | >| >   0-3           Reserved
> > | >| >   4             IS-IS graceful restart capable [4]
> > | >| >   5             IS-IS and BGP blackhole avoidance capable [6]
> > | >| >   6             IS-IS wide metric processing capable [3]
> > | >| >   7             IS-IS short metric processing capable [1]
> > | >| >   8             IS-IS hmac-md5 authentication capable [5]
> > | >| >   9             IS-IS Traffic Engineering support [3]
> > | >| >   10            IS-IS point-to-point over LAN [7]
> > | >| >   11            IS-IS Path Computation Server discovery [10]
> > | >| >   12            M-ISIS capable [8]
> > | >| >   13            IS-IS IPv6 capable [9]
> > | >| >   14-31         For future assignments
> >
>
>_______________________________________________
>Isis-wg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/isis-wg


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