[Isis-wg] draft-ietf-isis-gmpls-extensions-19.txt and unnumbered links

[Jon Berger <[e-mail]>]

Hello Kireeti, Yakov (and everyone else),

I have the following comments to make on
draft-ietf-isis-gmpls-extensions-19.txt.  My key concerns are in the area of
unnumbered links.


1.	Regarding the Link Local/Remote sub-TLV:
----------------------------------------------

In sections 3.2 and 3.3 (regarding local and remote interface addresses) of
the soon-to-be-RFCed draft-ietf-isis-traffic-05.txt, the following text
appears:

"If a router implements traffic engineering, it MUST include this sub-TLV."

I do not believe this to be true, as unnumbered links will use the Link
Local/Remote ID sub-TLV to identify a link's endpoints, rather than IP
addresses.

Since we cannot change the Traffic Engineering RFC(?), I would like to add a
comment similar to the following to section 1.1 of
draft-ietf-isis-gmpls-extensions-19.txt:

"For unnumbered links, the Link Local/Remote Identifiers sub-TLV is used to
identify a link.  For numbered links the IPv4 interface address and IPv4
neighbor address sub-TLVs are used to identify a link.  For each link only
one set of sub-TLVs should be present."


2.	Again, regarding the Link Local/Remote ID sub-TLV:
--------------------------------------------------------

In section 3.1 the draft specifies that this sub-TLV 'MUST NOT occur more
than once within the extended IS reachability TLV'.  The limitation should
actually be that the sub-TLV appear at most once per neighbor data
structure.

Likewise, where multiple instances of the sub-TLV are present, the draft
dictates that if the 'sub-TLV occurs more than once within the extended IS
reachability TLV, the receiver SHOULD ignore all these sub-TLVs'.  As well
as being incorrect for the reason stated above, I believe that this text is
slightly unclear as to whether the receiver should discard all of the
sub-TLVs, or just the superfluous ones (where my preference is the latter,
which allows the receiver to be generous, and is preferable to ignoring all
instances of the sub-TLV).  

My suggested replacement text for this section would be: 

'The Link Local/Remote Identifiers sub-TLV MUST NOT occur more than once per
IS neighbor data structure within the extended IS reachability TLV.  If the
Link Local/Remote Identifiers sub-TLV occurs more than once within an IS
neighbor data structure in an extended IS reachability TLV, the receiver
SHOULD ignore all bar the first of these sub-TLVs'.  

Note that this also corrects the misspelling of 'Identifiers'.


3.	Link Protection Type sub-TLV:
-----------------------------------

Section 3.2 is erroneous in the same way as section 3.1 - I suggest altering
the text to:

'The Link Protection Type sub-TLV MUST NOT occur more than once per IS
neighbor data structure within the extended IS reachability TLV.  If the
Link Protection Type sub-TLV occurs more than once within an IS neighbor
data structure in an extended IS reachability TLV, the receiver SHOULD
ignore all bar the first of these sub-TLVs'.  


4.	SRLG TLVs
---------------

I believe that the description of the flag byte should include a comment
specifically stating that the least significant bit determines whether Link
IDs or IPv4 addresses will be used in the TLV (bit set to 1 - IP addresses,
bit set to 0 - Link IDs).

I propose adding the sentence: 'For a numbered interface, IPv4 addresses
SHALL be used to describe the link, whereas for an unnumbered interface Link
IDs SHALL be used.'


5.	SRLG TLVs
---------------

I think that it would be advisable to have the following comment (as we do
in the Link ID sub-TLV description): 'If the Link Remote Identifier is
unknown, it is set to 0.'


Regards,
Jon

-----------------------------------------------
Jon Berger
Network Protocols Group
Data Connection Ltd (DCL)
Tel:  [phone]		
Fax:  [phone]
Email:  [e-mail]	
Web:  http://www.dataconnection.com




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