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

[Naiming Shen <[e-mail]>]

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
 ] >[e-mail]
 ] >https://www1.ietf.org/mailman/listinfo/isis-wg
 ] 

- Naiming

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