Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-caps-04.txt

From: [email-masked]
Date: Thu, 01 Dec 2005 15:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title		: IS-IS extensions for advertising router information
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-isis-caps-04.txt
	Pages		: 8
	Date		: 2005-12-1
	
This document defines a new optional IS-IS TLV named CAPABILITY, 
   formed of multiple sub-TLVs, which allows a router to announce its 
   capabilities within an IS-IS level or the entire routing domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-caps-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-isis-caps-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-isis-caps-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 02 Dec 2005 08:10:21 +0100

would'nt it make sense to make the router-id field
variable length (i.e. prepend it with a 1-octet router-id-length)
field to have a catch-all TLV for V6 as well ?

/hannes

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: Naiming Shen <[email-masked]>
Date: Fri, 02 Dec 2005 15:55:15 -0800

Hannes,

> field to have a catch-all TLV for V6 as well ?

My take on this is that, the router-id is just a 32bits number not
necessarilly associated with a particular address family to
simplify the operation. If there is any routing operation using
this capability feature, then it knows which system(with system-ID)
announces this capability-tlv thus an association can be made this
way.

thanks.
- Naiming

>> [email-masked] with the word unsubscribe in the body of 
>> the message.  You can also visit 
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>> subscription settings.
>>
>>
>> http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 05 Dec 2005 08:50:00 +0100

> announces this capability-tlv thus an association can be made this

naiming,

i believe association with systemID is not possible once you flood across
level boundaries (S/D bit set) - therfore you need a "connector" to point
back to the originator. (which i guess is the intention of including the
router-id).

he case that i am thinking about is "what if this originator lives
in an L1 V6-only island ?" and the L1L2 needs to generate the router-id field
based on TE-ID input and teh only information it can find is a V6 TE ID ?

/hannes

>>>     This document defines a new optional IS-IS TLV named 
>>> CAPABILITY,    formed of multiple sub-TLVs, which allows a router to 
>>> announce its    capabilities within an IS-IS level or the entire 
>>> routing domain.
>>>
>>> [email-masked] with the word unsubscribe in the body 
>>> of the message.  You can also visit

---

From: Naiming Shen <[email-masked]>
Date: Mon, 05 Dec 2005 00:26:50 -0800

Hannes,

> back to the originator. (which i guess is the intention of including the

that's true.

> based on TE-ID input and teh only information it can find is a V6 TE ID ?

but how do you get this V6 TE-ID into the L1L2 area in the first place?
also for a router running multi-protocol, it seems cumbersome to
announce all the 'router-id's belonging to each address family, and even
one address family might have multiple router-ids. this generization
would have too much overhead for a small isis capability TLV.

since this is the Capability TLV, we can define an optional AF router-id
sub-TLV within it, in your above example, a L1 router could announce
the cap TLV with a V6 TE-ID and being leaked into other areas.

- Naiming

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 05 Dec 2005 09:44:43 +0100

naiming,

point taken ... so why not remove the ipv4-alike-router-ID entirely and

define a

subTLV for  32-bit router-IDs
subTLV for 128-bit router-IDs

an implementation must include at least one of the two and
may include more than one of those subTLVs.

-> that would cover all cases and be most efficient.

/hannes

>>>>> CAPABILITY,    formed of multiple sub-TLVs, which allows a router 
>>>>> to announce its    capabilities within an IS-IS level or the entire 
>>>>> routing domain.
>>>>>
>>>>> To remove yourself from the I-D Announcement list, send a message 
>>>>> to [email-masked] with the word unsubscribe in the 
>>>>> body of the message.  You can also visit

---

From: Naiming Shen <[email-masked]>
Date: Mon, 05 Dec 2005 01:21:19 -0800

Hannes,

> point taken ... so why not remove the ipv4-alike-router-ID entirely and

i think to have a fixed/stable router-id regardless of address family
is useful; and in most cases it's sufficient. only in the case of
ipv6 te for inter-area like applications, we could add an optional
sub-tlv to that. and isis is not the only one to use a 32bit router-id
for the protocol.

- Naiming

>>>>>> to announce its    capabilities within an IS-IS level or the 
>>>>>> entire routing domain.
>>>>>>

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 05 Dec 2005 10:35:32 +0100

[ ... ]
> sub-tlv to that. and isis is not the only one to use a 32bit router-id

i slightly disagree ... capabilities announcment should be an AF-indep. function.

i do see some value in a fixed/stable ID, however this one should be AF-indep.

so if you want to have a fixed/stable ID then you should preserve the sys-ID of
the originating IS and not re-use the AF-dependend TE-ID.

/hannes

---

From: Naiming Shen <[email-masked]>
Date: Mon, 05 Dec 2005 10:39:38 -0800

32bit number is a good choice in implementation for router-id and it
also aligns with many other protocols. the fact that the
ipv4 address is a 32bit number is purely coincident;-)
the isis system-id does not give us anything more, it can not be
passed into other areas just as the V6 TE-ID.

- Naiming

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 05 Dec 2005 20:46:32 +0100

:-) - ok so let me summarize the required amendments:

- specify a v6 subTLV router-id

- add a note to zero out the initial router-id
   in case of a v6-only TE speaker
   (and of course add the v6 router-id subTLV)

/hannes

---

From: Naiming Shen <[email-masked]>
Date: Mon, 05 Dec 2005 11:51:21 -0800

>   (and of course add the v6 router-id subTLV)

there is no need to zero out the router-id. it's a unique
number even v6-only TE speaker needs one. just like v6
only BGP needs a 32-bit id.

- Naiming

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 05 Dec 2005 21:15:30 +0100

naiming,

i don't think that a V6 only TE speaker should/will have a 32-bit router-ID.

BGP is a different case as the router-ID is a day-1 _mandatory_ part
of the protocol - in IS-IS the 32-bit router-ID is an _optional_ extension
that a V6 only speaker will not include ...

are you mandating that a V6 TE speaker must include a V4 router-ID ?

/hannes

---

From: Naiming Shen <[email-masked]>
Date: Mon, 05 Dec 2005 15:05:13 -0800

Hannes,

> are you mandating that a V6 TE speaker must include a V4 router-ID ?

Not a V4 router-ID.

The draft requires the capability TLV to have a 32-bit unique number,
does not matter they are V6 TE speaker or not. this number does not
change back and forth just because a router configure changes from
multiprotocol into V6 only or not. this capabilty is used for
router generic information. the number is the key into the capability
database. 32-bits is just a nice number from implementation point
of view.

- Naiming

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 06 Dec 2005 00:54:41 +0100

> database. 32-bits is just a nice number from implementation point

let give an example for clarification: V6-only speaker -> what TLVs to generate ?

TLV140 (= IPv6 TE Router ID )

a. TLV 140, TLV 134, use content of TLV 134 as router-id
b. TLV 140, zero router-id, use content of TLV 140 as router-id
            (encoded as V6 subTLV)
c. TLV 140, fill router-id field based on local heuristics

thoughts ?

/hannes

---

From: Naiming Shen <[email-masked]>
Date: Mon, 05 Dec 2005 16:53:47 -0800

I actually don't have any preference on how this 32bit number
is derived. It's an operation/implementation detail. It may
or may not come out from this V6-TE-TLV value at all, it might
be part of the system-id as long as it's unique and configurable,
or might be the same as V6 BGP router-id, or LDP router-id.
Anything is fine as long as the implementation allows it to
be controlled by operators.

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Wed, 07 Dec 2005 23:29:59 -0800

Hi folks,

After some discussion on this list and among the authors
of this draft, I have made some changes to the ver -04.txt.
the diff is enclosed. Please send comment if you have.

thanks.
- Naiming
*** draft-ietf-isis-caps-04.txt	2005-12-07 21:35:08.206211472 -0800
--- draft-ietf-isis-caps-05.txt	2005-12-07 23:04:32.258751536 -0800
***************
*** 54,59 ****
--- 54,61 ----
     document are to be interpreted as described in RFC-2119 [i]. 

+ Vasseur et al.                                                [Page 1]
+ 
  draft-ietf-isis-caps-04.txt                               November 2005 
  
  Table of Contents 
***************
*** 86,91 ****
--- 88,96 ----
       2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE-
       NODE-CAP]) allows an LSR to advertise its Point To Multipoint 
       capabilities ([P2MP] and [P2MP-REQS]). 
+ 
+      3. Inter-area traffic engineering: Advertisement of the IPv4
+      and/or the IPv6 Traffic Engineering Router IDs.
        
     The use of IS-IS for Path Computation Element (PCE) discovery may 
     also be considered and will be discussed in the PCE WG. 
***************
*** 157,168 ****
      
  3. Elements of procedure 
      
!    A router which generates a capability TLV MUST also generate a 
!    Traffic Engineering Router ID TLV (134) at each level for which it 
!    generates a router capability TLV. 
!     
!  
!  
  Vasseur et al.                                                [Page 3] 
  
  draft-ietf-isis-caps-04.txt                               November 2005 
--- 162,175 ----
      
  3. Elements of procedure 
      
!    A router which generates a CAPABILITY TLV MUST have a Router ID
!    which is a 32 bit number. The ID MUST be unique within the IS-IS
!    area. If the router generates any capability TLVs with domain
!    flooding scope then the ID MUST also be unique within the IS-IS
!    routing domain.
! 
! 
! 
  Vasseur et al.                                                [Page 3] 
  
  draft-ietf-isis-caps-04.txt                               November 2005 
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg