Subject: Re: [Isis-wg] Agenda for Vienna ?

From: Hannes Gredler <[email-masked]>
Date: Tue, 1 Jul 2003 16:51:47 +0200

On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote:

| 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

nice work - any idea why the capability bits are aligned in units
of 32bits ? - wouldn't it make more sense [and be in the good spirit
of IS-IS] to have variable packing on byte boundaries ? 

/hannes

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

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 1 Jul 2003 20:00:42 +0200

| folks,

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

---

---

From: Jeff Learman <[email-masked]>
Date: Tue, 01 Jul 2003 15:21:10 -0400

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.

I suppose that could be made clear in the text.

---

From: Shankar Vemulapalli <[email-masked]>
Date: Tue, 1 Jul 2003 16:58:56 -0700 (PDT)

Hi Naiming & Co -

I am not sure on the scope of the "Capability-TLV"  -
Because, there are some other capabilities that can be included
in the capability-TLV in addition to what is mentioned in the draft.

For ex.: TLV 137 [dyn-hostname] is a capability of the rtr to send
           the dyn-hostname information.
         TLV 240 [p2p 3-Way Handshake] is also another capability of
           the rtr.

So, my question is, what criteria we determine to put in to say that the
router is capable of doing so & so ?
Or - are we OK to add the above two to the existing list ?

Also, "Refernces" section can be updated with the latest info.
For ex.: [6] is RFC 3277

Just my rumblings..

Thanks,

/Shankar

---

From: Naiming Shen <[email-masked]>
Date: Tue, 01 Jul 2003 19:02:39 -0700

Hannes,

 ] On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote:
 ] 
 ] | 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
 ] 
 ] nice work - any idea why the capability bits are aligned in units
 ] of 32bits ? - wouldn't it make more sense [and be in the good spirit
 ] of IS-IS] to have variable packing on byte boundaries ? 

thanks. this picture, Figure 1, must be done by a more OSPF oriented
person;-) but the TLV itself is not really aligned with 32bits, there
is two bytes type/length in front of the TLV. This capability flag
is chosen to be 32bits I think is to align with OSPF's choice(used to
be in the same draft), but it's also a nice number to start with.
We didn't intentionally to have this TLV to be 32bits aligned.

thanks.

 ] 
 ] /hannes
 ] 

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Tue, 01 Jul 2003 19:12:57 -0700

Hannes,

 ] 
 ] 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;

agree with Jeff's comment. the draft meant to say the current
implemented capabilities to be announced, unless the configuration
disables them. this is in section 4:

   If this TLV is included in the LSP, the router SHOULD set all
   the defined bits corresponding to the capabilities which the
   software supports, unless they are explicitly configured off.

thanks.

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

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Tue, 01 Jul 2003 19:25:56 -0700

Hi Shankar,

 ] Hi Naiming & Co -
 ] 
 ] I am not sure on the scope of the "Capability-TLV"  -
 ] Because, there are some other capabilities that can be included
 ] in the capability-TLV in addition to what is mentioned in the draft.
 ] 
 ] For ex.: TLV 137 [dyn-hostname] is a capability of the rtr to send
 ]            the dyn-hostname information.
 ]          TLV 240 [p2p 3-Way Handshake] is also another capability of
 ]            the rtr.
 ] 

For those two, I think the initial thinking was that, the Dyn-hostname
is flooded everywhere, one can easily see it, and the 3way handshake
is such a basic thing for p2p, we assumed it didn't need to cost a bit.
But they can be added if folks think so.

I guess Nagi was asking the similar thing in another email, and this
draft is not meant to be inclusive on those features. We can add the
existing one in as people agree, and with new features being developed later,
people can include a new capability bit in their document with ietf
consensus.

 ] So, my question is, what criteria we determine to put in to say that the
 ] router is capable of doing so & so ?
 ] Or - are we OK to add the above two to the existing list ?
 ] 
 ] Also, "Refernces" section can be updated with the latest info.
 ] For ex.: [6] is RFC 3277

sure. thanks.

 ] 
 ] Just my rumblings..
 ] 
 ] Thanks,
 ] 
 ] 
 ] /Shankar
 ] 
 ] At 3:21pm 07/01/03 -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.
 ] >
 ] > 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
 ] > >[email-masked]
 ] > >https://www1.ietf.org/mailman/listinfo/isis-wg
 ] >
 ] >
 ] > _______________________________________________
 ] > Isis-wg mailing list
 ] > [email-masked]
 ] > https://www1.ietf.org/mailman/listinfo/isis-wg
 ] >

- Naiming

---

From: Shankar Vemulapalli <[email-masked]>
Date: Tue, 1 Jul 2003 20:21:34 -0700 (PDT)

Hi Naiming -

Thanks for getting back.

Agree with your reasoning below - But if we apply the reasoning to the
capabilities mentioned in the draft - bit [7] for ISIS-short metric
is as you know is the default in every possible implementation :-)

So, we as well can spare this bit for some other capability ?

Just a thought -

/Shankar

---

From: Naiming Shen <[email-masked]>
Date: Tue, 01 Jul 2003 20:40:58 -0700

Hi Shankar,

 ] Hi Naiming -
 ] 
 ] Thanks for getting back.
 ] 
 ] Agree with your reasoning below - But if we apply the reasoning to the
 ] capabilities mentioned in the draft - bit [7] for ISIS-short metric
 ] is as you know is the default in every possible implementation :-)
 ] 

For this particular one, the original draft didn't have that. Until
one day I spent lots of hours on one particular problem and couldn't
easily figure out what went wrong. It turned out the "metric style"
default was changed from being "short" to "wide". Thus I was thinking
it actually was useful to put the "short metric" as the capability
in, it would be nice in the future to have software to detect there
is someone on the network is using a different style than me and
give out a warning message.

thanks.

 ] So, we as well can spare this bit for some other capability ?
 ] 
 ] Just a thought -
 ] 
 ] 
 ] /Shankar
 ] 
 ] At 7:25pm 07/01/03 -0700, Naiming Shen wrote:
 ] >
 ] > Hi Shankar,
 ] >
 ] >  ] Hi Naiming & Co -
 ] >  ]
 ] >  ] I am not sure on the scope of the "Capability-TLV"  -
 ] >  ] Because, there are some other capabilities that can be included
 ] >  ] in the capability-TLV in addition to what is mentioned in the draft.
 ] >  ]
 ] >  ] For ex.: TLV 137 [dyn-hostname] is a capability of the rtr to send
 ] >  ]            the dyn-hostname information.
 ] >  ]          TLV 240 [p2p 3-Way Handshake] is also another capability of
 ] >  ]            the rtr.
 ] >  ]
 ] >
 ] > For those two, I think the initial thinking was that, the Dyn-hostname
 ] > is flooded everywhere, one can easily see it, and the 3way handshake
 ] > is such a basic thing for p2p, we assumed it didn't need to cost a bit.
 ] > But they can be added if folks think so.
 ] >
 ] > I guess Nagi was asking the similar thing in another email, and this
 ] > draft is not meant to be inclusive on those features. We can add the
 ] > existing one in as people agree, and with new features being developed lat
er,
 ] > people can include a new capability bit in their document with ietf
 ] > consensus.
 ] >
 ] >  ] So, my question is, what criteria we determine to put in to say that th
e
 ] >  ] router is capable of doing so & so ?
 ] >  ] Or - are we OK to add the above two to the existing list ?
 ] >  ]
 ] >  ] Also, "Refernces" section can be updated with the latest info.
 ] >  ] For ex.: [6] is RFC 3277
 ] >
 ] > sure. thanks.
 ] >
 ] >  ]
 ] >  ] Just my rumblings..
 ] >  ]
 ] >  ] Thanks,
 ] >  ]
 ] >  ]
 ] >  ] /Shankar
 ] >  ]
 ] >  ] At 3:21pm 07/01/03 -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.
 ] >  ] >
 ] >  ] > 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
 ] >  ] > >[email-masked]
 ] >  ] > >https://www1.ietf.org/mailman/listinfo/isis-wg
 ] >  ] >
 ] >  ] >
 ] >  ] > _______________________________________________
 ] >  ] > Isis-wg mailing list
 ] >  ] > [email-masked]
 ] >  ] > https://www1.ietf.org/mailman/listinfo/isis-wg
 ] >  ] >
 ] >
 ] > - Naiming
 ] >

- Naiming

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 2 Jul 2003 07:30:33 +0200

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

---

From: Jeff Learman <[email-masked]>
Date: Wed, 02 Jul 2003 01:41:22 -0400

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" ;)

Jeff

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 2 Jul 2003 08:07:54 +0200

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

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

---

From: stefano previdi <[email-masked]>
Date: Wed, 2 Jul 2003 08:13:27 +0200

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

---

From: Jeff Learman <[email-masked]>
Date: Wed, 02 Jul 2003 09:04:57 -0400

I won't comment on all the items, but I'd think it would be useful
to know whether a router is ignoring wide metrics, and you can't tell
whether it's using them or not in its SPF calculation from looking
at its TLVs, can you?  However, the description for the item probably
isn't clear enough for us to know whether "wide metric capable" means
whether it would emit wide metrics or whether it would use them
in calculations, so perhaps more text is in order there.

Or perhaps I'm misremembering, and no router would ever
emit wide metrics and yet disregard them in SPF.

Regards,
Jeff

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 02 Jul 2003 12:47:06 -0700

>bits&flags but not sure it makes a lot of sense.

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)???

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

OK

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.

Not needed.

Not needed.

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

OK

    12            M-ISIS capable [8]

Not needed.

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

---

From: Naiming Shen <[email-masked]>
Date: Wed, 02 Jul 2003 15:26:02 -0700

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

- Naiming

---

From: Shankar Vemulapalli <[email-masked]>
Date: Wed, 2 Jul 2003 17:18:06 -0700 (PDT)

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