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

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

>-----Original Message-----
>From: Yakov Rekhter [mailto:yakov@juniper.net] 
>Sent: Friday, May 28, 2004 6:11 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,
>
>> 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)
>
>That is correct.
>
>> 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?
>
>I think that the editor of that RFC would be the more 
>appropriate person to elaborate on this.
>

Dear Yakov, 

So you agree that there is a (possible) disconnect and we either need some
clarification (from editors of the RFC) or fix the specs to avoid confusion.


BTW as you may recall there has been some discussions on the mailing list on
this issue in past. Let's try to close the issue while we are on it. 

Thanks

Regards... Zafar 

>Yakov.
>  
>> 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.
>> >
>> 
>