RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt

["zafar ali" <zali@cisco.com>]

Dear Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar

>-----Original Message-----
>From: Yakov Rekhter [mailto:yakov@juniper.net] 
>Sent: Tuesday, May 25, 2004 1:51 PM
>To: zafar ali
>Cc: 'John Drake'; ccamp@ops.ietf.org; 'Anca Zamfir'; 'Adrian 
>Farrel'; dpapadimitriou@psg.com; aruns@movaz.com
>Subject: Re: I-D 
>ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
>
>
>Zafar,
>
>> Hi John,
>> 
>> Sorry for the delay in reply. In this ID we combined the 
>following two
>> drafts:
>> 
>> 1. Component Link Recording and Resource Control for GMPLS Link 
>> Bundles, 
>> 
>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resou
>rce-control-b
>> undle-03.txt. We had discuss and agreement on the content on 
>this draft
>> (especially need for RRO sub-object). 
>> 
>> 2. Identification of Component Links of Unnumbered Interfaces, 
>> 
>http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00.t
>> xt.
>> 
>> I think your question is for the portion of ID that came from (2), 
>> correct?
>> 
>> Assuming this, here is the rationale.
>> 
>> RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object.
>> 
>>    Type Length Format     Description
>>    
>--------------------------------------------------------------------
>>     1      8   IPv4 Addr. IPv4
>>     2     20   IPv6 Addr. IPv6
>>     3     12   See below  IF_INDEX                (Interface Index)
>>     4     12   See below  COMPONENT_IF_DOWNSTREAM (Component 
>interface)
>>     5     12   See below  COMPONENT_IF_UPSTREAM   (Component 
>interface)
>> 
>> We need following new TLVs to describe Numbered IF_IDs using IF_ID 
>> RSVP_HOP Object.
>> 
>> IPv4 - DOWNSTREAM (Component IF)
>> IPv4 - UPSTREAM (Component IF)
>> IPv6 - DOWNSTREAM (Component IF)
>> IPv6 - UPSTREAM (Component IF)
>> 
>> As the definition in RFC3471 are not sufficient to identify 
>the above 
>> mentioned cases. Agreed? This is where the discussion started.
>
>Could yoy please explain why there is a need for allowing 
>separate downstream and upstream for component links of a 
>bundled link, but there is no such need for plain links ?
>

I wish bundling draft would clearly state the same. Instead it states, "The
choice of the component link to use is always made by the sender of the
Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], the sender
chooses a component link in each direction)", and makes room for
interpretation that the forward and reverse may use the same TE link but
different component links. Furthermore, if this is true, can you please
elaborate on the motivation behind using the following (different) TLVs, for
the IF_ID RSVP_HOP, for the unnumbered case? 

4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)

>> It was pointed out that some implementations have IF index 
>assignment 
>> such that IF indexes are only unique within the TE link they belong 
>> to. I.e., assumption that IF_indexes are NOT box wide unique is not 
>> valid across implementations. In order to accommodate such 
>> implementation, we came up with what is in the ID at the present 
>> moment.
>
>That is totally unreasonable. Standards are *not* produced to 
>accommodate a particular implementation, and especially to 
>accommodate some fairly random assumption(s) made by the 
>implementation. So, fix the implementation !!!
>  

I fully agree with you. 

>> Given this, can you please provide more feedback on how you can 
>> improve
>> the ID? 
>
>See above.
>
>Yakov.
>