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

From: "Jonathan Harrison" <[email-masked]>
Date: Tue, 8 Mar 2005 11:52:48 -0000

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

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.

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.

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

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

Let me know what you think!
Thanks,
Jon

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

---

From: Naiming Shen <[email-masked]>
Date: Tue, 08 Mar 2005 21:00:26 -0800

Jonathan,

thanks for the comments, see some reply inline,

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

If the receiving router is in the same area as the originating one,
then it knows the systemID of the sender from the LSPs, there is no
need to attach a systemID again. If they are in different areas,
then systemID does not help, since you may not know how to get there.
With RouterID, you may have a route to this router which owns this ID,
it makes the service selection decision much easier, be it a TE or
something else. Yes, the routerID TLV is optional, but the
implementation can always generating the routerID when it advertises
the CAP TLV, also sometimes, have a route to the routerID is enough too.
Applications also don't want to know if they are using OSPF or IS-IS,
routerID is more generic.

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

On one hand it seems a little strict requirement, on the other hand,
can you trust the information from a router you can not even reach?
can you think of a specific appliction which works better if this
requirement is relaxed? also note that, we don't want to use IS-IS
or OSPF as a general information carrier.

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

two copies of the TLV, I think is talking about the CAP TLV, the
same sub-TLVs appear in two different LSPs, e.g. a TE proxy server
sub-TLV listed two different servers. there is no definite way of
determine which one is the most recent one, and hopefully this is
in a transient state, and it will converge.

if you are talking about one particular sub-TLV has so much data
which needs to use two seperate TLVs, then remember the "extended-TLV"
draft? which was exactly triggered by this CAP TLV discussion.

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

sounds fine with me. actually this "by L1 Routers" is not accurate,
a CAP TLV can also be generated by a "L2 or L1/L2 Routers".

thanks.
- Naiming

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