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

[Yakov Rekhter <yakov@juniper.net>]

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.