headers
Hannes Gredler | 1 Jul 2003 16:51
Favicon
Gravatar

Re: Agenda for Vienna ?

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
Permalink | Reply | 0 comments |
headers
Hannes Gredler | 1 Jul 2003 20:00
Favicon
Gravatar

Re: Agenda for Vienna ?

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]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Learman | 1 Jul 2003 21:21
Picon
Favicon

Re: Agenda for Vienna ?


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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Shankar Vemulapalli | 2 Jul 2003 01:58
Picon
Favicon

Re: Agenda for Vienna ?

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

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.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Naiming Shen | 2 Jul 2003 03:55

Re: Comments on Extensions to IS-IS for Advertising Optional Router Capabilities


Nagi,

thanks for the comments, some replies inline.

 ] Naiming & all,
 ] 
 ] I have a couple of questions on the draft.
 ] 
 ] 1) As you mentioned, this feature can be used in MPLS-TE environment (or) by
 ] the Network management (or) for some other informational purposes.
 ] 
 ] Having said that, Router-ID may not be available (if TE extensions are not
 ] implemented) in some implementations. How do we solve that? Shouldn't  we
 ] consider System-ID as the unique identity?
 ] 

I think Router-ID is something very simple to implement, does not need
to do it along with TE extensions. For this capability extension purpose,
it only needs to be an unique 32bits number in the IGP domain. For
example, it could use the "IP Interface Address" number in the LSP.
But since the router-id is such a useful thing, I would recommend
anyone implements this draft to use the "real" router id of the
router or the virtual router. This extension came up first with
the troubleshooting in mind, and if the router-id is a routable one,
it would be useful in operation with an IP address.

 ] 2) I think advertising the router capabilities do create security concerns.
 ] For example, if I advertise I don't have HMAC-MD5 capability, then an
 ] intruder can aim at that specific system.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Naiming Shen | 2 Jul 2003 04:02

Re: Agenda for Vienna ?


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
Permalink | Reply | 0 comments |
headers
Naiming Shen | 2 Jul 2003 04:12

Re: Agenda for Vienna ?


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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Naiming Shen | 2 Jul 2003 04:25

Re: Agenda for Vienna ?


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 ?
 ]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shankar Vemulapalli | 2 Jul 2003 05:21
Picon
Favicon

Re: Agenda for Vienna ?

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

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.
>  ]
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Naiming Shen | 2 Jul 2003 05:40

Re: Agenda for Vienna ?


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
 ]
(Continue reading)

Permalink | Reply | 0 comments |

Gmane