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

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

Dear Yakov, 

You mentioned that bundle draft does NOT mention/ use the following TLVs,
for the IF_ID RSVP_HOP, 

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

So what was the motivation behind such definition (two TLVs) in the RFC?
Furthermore, the RFC states: "For types 4 and 5, the Interface ID indicates
a bundled component link.". Can you please elaborate on this disconnect?  

Thanks

Regards... Zafar


>-----Original Message-----
>From: owner-ccamp@ops.ietf.org 
>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter
>Sent: Friday, May 28, 2004 10:25 AM
>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,
>
>> Dear Yakov,
>> 
>> Please see in-line.
>
>response in-line...
>
>> >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.
>> >txt.
>> >> 
>> >> 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.
>
>Good point. Perhaps the bundling draft should be clarified to 
>make it explicit that it is the same component link that is 
>used for both the forward and reverse direction.
>
>> 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)
>
>The bundling draft does not say anything about these two TLVs.
>  
>> >> 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.
>
>So, with this in mind let me propose that we clarify the 
>bundling text, as I suggested above, and then consider the 
>issue closed.
>
>Yakov.
>