Subject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt

From: Les Ginsberg <[email-masked]>
Date: Tue, 08 Mar 2005 13:29:08 -0800

Jonathan -

At 11:52 AM 3/8/2005 +0000, Jonathan Harrison wrote:

>JP, Rahul, Naiming,
>
>I've had a look at draft-ietf-isis-caps-00.txt.  Overall, it looks good, 
>but I have a few comments and suggestions below.
>
>1) The draft identifies the originator of the capabilities TLV using 
>router ID.  This is quite unusual for an IS-IS TLV, which normally use the 
>IS-IS system ID, and so the draft probably needs some additional 
>clarification as to why the router ID is used instead.  In particular, it 
>is worth noting that an IS-IS node is not required to advertise a router 
>ID unless it supports traffic engineering.
>
>If the aim of the draft is to add the ability to advertise a generic 
>capability using the IS-IS protocol, I think it makes more sense to use 
>the system ID to identify the advertising router.  (In this case, if an 
>individual capability or set of capabilities is TE-related and requires an 
>associated router ID or IP address, then this should be included in the 
>appropriate sub-TLV.)

There is one potential problem with using system ID. Technically, L1 system 
IDs are only required to be unique within the area. It is therefore 
possible for two L1 routers in different areas to have the same system ID, 
which would lead to ambiguity if both routers advertised capabilities TLVs 
which have domain wide scope. This problem is unlikely to occur in the real 
world, but it is possible and legal under the protocol definition.

>2) The draft states that a system should not use capability TLVs unless 
>the advertiser of the LSP containing the TLV is currently reachable by a 
>path at the appropriate level.  It would be good to explain the reason for 
>this requirement.

Sure. Here's an example.

If L1 router A generates a CAP TLV and floods it to L1/L2 routers S and T, 
they will flood it into the L2 domain. Now suppose the L1 area partitions, 
such that A and S are in one partition and T is in another. IP routing will 
still continue to work, but if A now issues a revised version of the CAP 
TLV, or decides to stop advertising it, S will follow suit, but T will 
continue to advertise the old version until the LSP times out.

Routers in other areas have to choose whether to trust T's copy of A's 
capabilities or S's copy of A's information - and they have no reliable way 
to choose (more on that below). By making sure that T stops leaking A's 
information, we remove the possibility that other routers will use stale 
information from A.

Basically, we are affording the same protection to the capabilities 
information that comes naturally to IP reachability TLVs i.e. don't use 
information from unreachable systems.

>It feels to me that this is an overly strict requirement, that may 
>restrict the type of information carried (and which will certainly make 
>implementation of the draft much harder).  While it may be the case that 
>some capabilities should only be used if the node advertising the 
>capability is reachable, I don't think we should insist that this is the 
>case for all capabilities.
>
>My preference would be to remove this restriction.  Instead, the 
>description of each capability sub-TLV should indicate whether 
>reachability is a requirement for accepting that sub-TLV.
>
>3) The draft touches on the issue of having multiple capabilities TLVs 
>with different contents, and the possibility of a TLV moving from one LSP 
>fragment to another - it is definitely a good thing to have the draft 
>consider this!  There is one thing I would suggest that might make such 
>considerations simpler...
>
>The draft states the following: "Where a receiving system has two copies 
>of a capabilities TLV from the same system which have different settings 
>for a given attribute, the procedure used to choose which copy shall be 
>used is undefined."  At a minimum, it would be good to explicitly say that 
>such a receiving system should choose one of the copies of the TLV to use 
>(instead of, for example, discarding both).  If possible, it would be good 
>to suggest some procedure for choosing between two copies of the TLV, to 
>ensure that behavior is consistent across the domain.

This was discussed at some length during the writing of the draft. Although 
it would be nice to have a deterministic way of deciding which of two 
copies of a TLV are newer, in order to do so we would have to introduce the 
equivalent of LSP sequence numbers per TLV along with all of the attendant 
issues of dealing with sequence # rollover. This type of solution was 
considered too heavyweight to deal with a problem which only occurs as a 
transient condition.

Other simpler schemes are possible (e.g. use the higher numbered LSP, or 
use the copy most recently received) but as the LSP database is 
distributed, one can encounter scenarios where different routers make 
different decisions at different moments in time, so we haven't 
accomplished much.

It should be noted this problem not unique to capabilities TLVs, The same 
issues arise for any TLV type (e.g. IS-neighbor) when the sending system 
moves the TLV from one LSP fragment to another. The draft describes 
recommended practices to minimize the occurrence of the transient 
disruption and the duration of such disruption if it is impossible to avoid 
moving a TLV (as it sometimes can be).

>Another question this raises for an implementer is this - how does a 
>router know if TLV A and TLV B are two copies of the same TLV, rather than 
>being different TLVs?

It is necessary to compare the contents. In particular, for a given source, 
the set of sub-TLVs advertised must be compared. Where two copies of the 
same sub-TLV are provided, then there is duplicate information.

>  If the capabilities TLV were to include an extra byte to identify a 
> particular instance of the TLV, then I think this would all become much 
> simpler.  (This identifier would also reduce the amount of checking 
> required in order to prevent the leaking of multiple copies of the same 
> TLV from level 2 into level 1.)
>
>4)  The second paragraph of section 4 has the phrase "...at least one 
>L1/L2 Router in every area of the domain MUST support the Router 
>CAPABILITY TLV."  I think this comes out a bit stronger than the intended 
>meaning!
>
>Would it be better to change the sentence to read as follows "In a network 
>where Router CAPABILITY TLVs with domain-wide scope originated by L1 
>Routers are required to be flooded across the entire domain, then it is 
>necessary for at least one L1/L2 Router in every area of the domain to 
>support the Router CAPABILITY TLV."

I don't have a problem with your wording or the current wording. :-)

>It may also be worth noting that this is an operational requirement, 
>rather than being something required for an implementation of the protocol.

I thought that was self-evident...maybe not?

    Les

>Let me know what you think!
>Thanks,
>Jon
>_______________________________________________
>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

---

From: "Don Goodspeed" <[email-masked]>
Date: Tue, 8 Mar 2005 13:55:36 -0800

Les,

On the router ID issue, according to RFC 3784, if one does not implement
traffic engineering, then advertisement of the router ID TLV is optional.

Since these boxes can never send capability TLVs (by the current
definition),
do we need to add text that overrides the optional language in RFC 3784?

The section I refer to is section 5:
   If a router does not implement traffic engineering, it MAY add or
   omit the Traffic Engineering router ID TLV.  If a router implements
   traffic engineering, it MUST include this TLV in its
LSP.Cheers,Don-----Original Message-----From: [email-masked]
[mailto:[email-masked]]On Behalf Of Les GinsbergSent: Tuesday,
March 08, 2005 1:29 PMTo: Jonathan HarrisonCc: [email-masked];
[email-masked]; [email-masked]: Re: [Isis-wg] Comments on
draft-ietf-isis-caps-00.txtJonathan -

    JP, Rahul, Naiming,

    1) The draft identifies the originator of the capabilities TLV using
router ID.  This is quite unusual for an IS-IS TLV, which normally use the
IS-IS system ID, and so the draft probably needs some additional
clarification as to why the router ID is used instead.  In particular, it is
worth noting that an IS-IS node is not required to advertise a router ID
unless it supports traffic engineering.

    If the aim of the draft is to add the ability to advertise a generic
capability using the IS-IS protocol, I think it makes more sense to use the
system ID to identify the advertising router.  (In this case, if an
individual capability or set of capabilities is TE-related and requires an
associated router ID or IP address, then this should be included in the
appropriate sub-TLV.)

  There is one potential problem with using system ID. Technically, L1
system IDs are only required to be unique within the area. It is therefore
possible for two L1 routers in different areas to have the same system ID,
which would lead to ambiguity if both routers advertised capabilities TLVs
which have domain wide scope. This problem is unlikely to occur in the real
world, but it is possible and legal under the protocol definition.

  Sure. Here's an example.

    It feels to me that this is an overly strict requirement, that may
restrict the type of information carried (and which will certainly make
implementation of the draft much harder).  While it may be the case that
some capabilities should only be used if the node advertising the capability
is reachable, I don't think we should insist that this is the case for all
capabilities.

    My preference would be to remove this restriction.  Instead, the
description of each capability sub-TLV should indicate whether reachability
is a requirement for accepting that sub-TLV.

    The draft states the following: "Where a receiving system has two copies
of a capabilities TLV from the same system which have different settings for
a given attribute, the procedure used to choose which copy shall be used is
undefined."  At a minimum, it would be good to explicitly say that such a
receiving system should choose one of the copies of the TLV to use (instead
of, for example, discarding both).  If possible, it would be good to suggest
some procedure for choosing between two copies of the TLV, to ensure that
behavior is consistent across the domain.

  This was discussed at some length during the writing of the draft.
Although it would be nice to have a deterministic way of deciding which of
two copies of a TLV are newer, in order to do so we would have to introduce
the equivalent of LSP sequence numbers per TLV along with all of the
attendant issues of dealing with sequence # rollover. This type of solution
was considered too heavyweight to deal with a problem which only occurs as a
transient condition.

  Other simpler schemes are possible (e.g. use the higher numbered LSP, or
use the copy most recently received) but as the LSP database is distributed,
one can encounter scenarios where different routers make different decisions
at different moments in time, so we haven't accomplished much.

  It should be noted this problem not unique to capabilities TLVs, The same
issues arise for any TLV type (e.g. IS-neighbor) when the sending system
moves the TLV from one LSP fragment to another. The draft describes
recommended practices to minimize the occurrence of the transient disruption
and the duration of such disruption if it is impossible to avoid moving a
TLV (as it sometimes can be).

  It is necessary to compare the contents. In particular, for a given
source, the set of sub-TLVs advertised must be compared. Where two copies of
the same sub-TLV are provided, then there is duplicate information.

     If the capabilities TLV were to include an extra byte to identify a
particular instance of the TLV, then I think this would all become much
simpler.  (This identifier would also reduce the amount of checking required
in order to prevent the leaking of multiple copies of the same TLV from
level 2 into level 1.)

    4)  The second paragraph of section 4 has the phrase "...at least one
L1/L2 Router in every area of the domain MUST support the Router CAPABILITY
TLV."  I think this comes out a bit stronger than the intended meaning!

    Would it be better to change the sentence to read as follows "In a
network where Router CAPABILITY TLVs with domain-wide scope originated by L1
Routers are required to be flooded across the entire domain, then it is
necessary for at least one L1/L2 Router in every area of the domain to
support the Router CAPABILITY TLV."

     Les

---

From: Les Ginsberg <[email-masked]>
Date: Tue, 08 Mar 2005 14:08:10 -0800

At 01:55 PM 3/8/2005 -0800, Don Goodspeed wrote:
>Since these boxes can never send capability TLVs (by the current definition),

Don -

It doesn't seem to me that we are conflict with RFC 3784. What probably 
needs to be said is that a router which sends capability TLVs SHOULD 
(MUST?) also send a router ID TLV.

I think that sort of thing is probably assumed because the examples of the 
usage of the capabilities TLV are TE related - but it does seem better if 
it were explicitly stated since we are not restricting the use of the 
capabilities TLV to TE only.

    Les

>    traffic engineering, it MUST include this TLV in its LSP.
>Cheers,
>
>Don
>
>  -----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf 
>Of Les Ginsberg
>Sent: Tuesday, March 08, 2005 1:29 PM
>To: Jonathan Harrison
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Isis-wg] Comments on draft-ietf-isis-caps-00.txt
>
>Jonathan -
>
>>router ID.  This is quite unusual for an IS-IS TLV, which normally use 
>>the IS-IS system ID, and so the draft probably needs some additional 
>>individual capability or set of capabilities is TE-related and requires 
>>an associated router ID or IP address, then this should be included in 
>>the appropriate sub-TLV.)
>which have domain wide scope. This problem is unlikely to occur in the 
>real world, but it is possible and legal under the protocol definition.
>
>>path at the appropriate level.  It would be good to explain the reason 
>>for this requirement.
>Sure. Here's an example.
>
>such that A and S are in one partition and T is in another. IP routing 
>will still continue to work, but if A now issues a revised version of the 
>CAP TLV, or decides to stop advertising it, S will follow suit, but T will 
>capabilities or S's copy of A's information - and they have no reliable 
>way to choose (more on that below). By making sure that T stops leaking 
>A's information, we remove the possibility that other routers will use 
>stale information from A.
>
>>used is undefined."  At a minimum, it would be good to explicitly say 
>>that such a receiving system should choose one of the copies of the TLV 
>>to use (instead of, for example, discarding both).  If possible, it would 
>>be good to suggest some procedure for choosing between two copies of the 
>>TLV, to ensure that behavior is consistent across the domain.
>two copies of a TLV are newer, in order to do so we would have to 
>introduce the equivalent of LSP sequence numbers per TLV along with all of 
>the attendant issues of dealing with sequence # rollover. This type of 
>solution was considered too heavyweight to deal with a problem which only 
>occurs as a transient condition.
>
>disruption and the duration of such disruption if it is impossible to 
>avoid moving a TLV (as it sometimes can be).
>
>>router know if TLV A and TLV B are two copies of the same TLV, rather 
>>than being different TLVs?
>source, the set of sub-TLVs advertised must be compared. Where two copies 
>of the same sub-TLV are provided, then there is duplicate information.
>
>>network where Router CAPABILITY TLVs with domain-wide scope originated by 
>>L1 Routers are required to be flooded across the entire domain, then it 
>>is necessary for at least one L1/L2 Router in every area of the domain to