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

Hi Naiming -

Some ideas/thoughts -

a]
Since most of the TLVs  have a way to get identified to start with the
information in the LSPs - may be we can include information in the Capability
TLV for those which doesnt' have the TLVs -
for. ex:  ISIS & BGP Blackhole Avoidance.

b]
As you said below, may be increasing the size of the TLV to 2 or 3 bytes could
be a better idea which may let include all the TLVs

and
c]
It would be good idea to define the "scope" of the Capability TLV and also
describe the reason why a TLV included vs not the other TLV in the draft.

d]
Or even specify which TLVs should be included as "Mandotory" vs the others.

Thanks,

/Shankar

At 3:26pm 07/02/03 -0700, Naiming Shen wrote:
>
>
> Les, Stefano, Hannes and Jeffs,
>
>
> thanks for the good comments, a couple of things I want to mention
> about this capability TLV.
>
>
> - this TLV can be "flooded" over the entire IGP domain, not exactly
>   like LSPs which is only confined in area/level.
>
> - one of the purposes of this TLV is for network troubleshooting, so
>   even if there are ways to exmain the entire fragments of LSPs from
>   one particular router to find answer, it still helps to list
>   all of them in a well-known place and a show command can list them
>   all together. I think this will be easier than to find a way to
>   dump raw ISIS packets and search for one particular feature.
>
> - the capabilities of this TLV can be group into 3 categories,
>    (1) for protocol functionality, such as the Path computation
>   application for example;
>    (2) for software to detect misconfig or mismatch
>   automatically, for example, short/wide capability bits. We can
>   specify here(not yet) if one supports short-only, short-and-wide
>   or wide-only mode, we can announce them with those two bits. If
>   any router in the area detect a mismatch(i only run wide-only,
>   and someone in the area runs short-only), it can spit out a
>   warning message. NOTICE, this is not for protocol use, protocol
>   can still run as is, but it gives us a powerful auto-checking
>   mechanism to detect errors during transtion. This may not just
>   be short/wide application, other transitions later on, for example,
>   diff IPv6 schemes which requires area wide coordination, we could
>   use that;
>    (3) informational. this is only for operators troubleshooting,
>   rathar than ask them to have tcpdump on ISIS packets and
>   search for TLVs, it allows a router to announce them explicitly
>   in a well-known TLV(not to mention for non-LSP related things).
>   Most of the routers now have a way to display system-id vs hostname
>   using dynamic-hostname TLV, similarly they can
>   later on have a command to display the router-id, with a list of
>   capabilities. Certain things like IPv6 capability, it will be nice
>   to know this router is capable of running IPv6 in the current
>   version of software, but (maybe due to misconfig or something) none
>   of the interfaces is configured with IPv6, then even you dump the
>   packets, there is no indication of "IPv6 capability" of the router.
>
> - I do agree with most of you that, in the current draft, the meaning
>   of each capability is unclear. We need to list each one of them(if
>   they are needed) to define exactly the meaning of them, and how do
>   people use them, the short/wide bit is a good example. People should
>   comment on those and we'll include them in the next version.
>
> some comments inline,
>
>  ] 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?
>
> see above.
>
>  ]
>  ] 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.
>
> we can discuss this and include more info on each bit, see above.
>
>  ]
>  ]
>  ] 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.
>
> Usually when a ISP running ISIS in the domain, they don't use the same
> IP address for their router-id/loopback0-address. It's a good idea anyway
> to define an unique IP address for each router in the domain. Even if
> the systemID is used instead of router-id, as you mentioned, this systemID
> does not need to be unique in the domain, and this TLV can be "flooded"
> over the entire domain, so what will be the result? the later one always
> overwrites the previous one even they are from different sources? So use
> router-id and require they be unique(from operation point of view) is
> important.
>
>  ]
>  ] 2)Requiring the length field in a sub-TLV to be set to a multiple of 4
>  ] seems very non-IS-IS-like.
>
> Only the capability flag sub-TLV, not the other sub-TLVs. But this is
> a minor issue, I don't have strong opinion on this.
>
>  ]
>  ] 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.
>
> each router suppose to advertise one TLV, but in the level boundary, a
> router can advertise one for itself and many for other. Still it needs
> to have this capability flag for each one of them.
>
>  ]
>  ] 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.
>
> True, we can change this to one, two or three bytes instead, just to
> avoid the suspicion of OSPF blood contamination:-)
>
> thanks.
>
>  ]
>  ]     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.t
> xt
>  ] > > | >| >
>  ] > > | >| >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 capabili
> ty
>  ] > > | >| >   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
>  ] >Isis-wg@ietf.org
>  ] >https://www1.ietf.org/mailman/listinfo/isis-wg
>  ]
>
> - Naiming
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www1.ietf.org/mailman/listinfo/isis-wg
>

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg