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

[Yakov Rekhter <yakov@juniper.net>]

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.

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