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

[Yakov Rekhter <yakov@juniper.net>]

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-resource-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 ?

> 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 !!!
  
> Given this, can you please provide more feedback on how you can improve 
> the ID? 

See above.

Yakov.