Re: I-D ACTION:draft-ietf-isis-caps-04.txt

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

Hannes Gredler said the following on 12/05/2005 03:54 PM:
> 
> 
> Naiming Shen wrote:
> 
>> Hannes,
>>
>> Hannes Gredler said the following on 12/05/2005 12:15 PM:
>>
>>> 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 ?
>>>
>>
>> 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.
> 
> 
> 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