Re: RSVP-TE: specifying links in EROs

This is what I thought.  I also thought that using ERO subobjects with 
/32 addresses matching interface addresses would work.  But I can't find 
anything in the RFCs that documents this behavior.

I also thought the IF-ID subobject (used for unnumbered links) would 
work, but the RFC says otherwise.  It says only that the subobject can 
be used to define an abstract node via router-ID and IF-ID, and says 
that the actual ERO processing does not change from what was previously 
documented.

-- David


Don Fedyk wrote:
> Hi David
> 
> It was my impression that if you use numbered links, the ERO could
> specify the links as well. 
> 
> Don 
> 
> 
> 
> 
>>-----Original Message-----
>>From: [email protected] 
>>
>>I've been reading through RFCs 3209, 3473, and 3477.
>>
>>I can't seem to find any mechanism that an originating node 
>>can use to 
>>fully specify both the nodes and links of an ERO.  All the discussion 
>>deals with abstract nodes, and doesn't say a thing about how 
>>to select 
>>specific links between the nodes.
>>
>>Clearly, the chosen link must satisfy the LSP's constraints 
>>(QoS, CoS, 
>>link colors, etc.), but when there are multiple compatible links, the 
>>RFCs appear to be silent.
>>
>>If an originating node wishes to fully specify the path through the 
>>network, down to the granularity of individual links, is there an 
>>RFC-specifie behavior that will allow this?
>>
>>One can obviously build RSVP-TE with rules to permit this (such as 
>>selecting interfaces that exactly match ERO subobjects when 
>>there is a 
>>compatible match), but I can't find anything in the RFCs that discuss 
>>this.  They all merely state that the subobjects define 
>>abstract nodes 
>>(which may be a single router), but with no more granularity 
>>than that.
>>
>>Surely, given the requirements and design goals of GMPLS, 
>>there must be 
>>a mechanism that I've missed.  Can anyone help?
>>
>>-- David
>>
>>
>>
>>
>>