The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Markus Jork wrote:
> 
> We just seem to be interpreting one sentence in the spec
> differently where it defines the TC_AddFlowspec semantics:
> 
>    If the
>    traffic control service updates the flowspec, the call will
>    also return the updated object as Fwd_Flowspec.
> 
> It all depends on what "If" means :-)
> My interpretation was that a modified 'Fwd_Flowspec' *may* be computed
> and if so, it gets sent upstream. The spec doesn't say you *should*
> compute a Fwd_Flowspec and in what way.

If traffic control updates the FLOWSPEC is the important condition.  I 
think section 2.2 (the merging rules) of RFC 2205 explains when this 
happens:

	...
	3. (Re, Resv_Te) and Path_Te are passed to traffic control.
	   Traffic control will compute the effective flowspec as the
	   "minimum" of Path_Te and Resv_Te, in a service-dependent
	   manner.

I would assume that traffic control will update the flowspec if the 
minimum computed in step 3 is different from the requested flowspec.

But you're right that we're probably splitting hairs here.  If an 
implementation chooses not to do this, and forwards the full-size 
FLOWSPEC, I don't think it will break anything - the PHOP should clip 
his reservation anyway.

But it may lead to inefficient behavior in a multicast scenario.  My 
effective TSPEC (Path_Te) may be different from my upstream neighbor's 
(due to having different senders on different PHOP interfaces.)  If my 
upstream neighbor has a larger effective TSPEC than I do, he will clip 
my outbound FLOWSPEC to a larger value than I have installed in my 
hardware - which may result in lost packets.

If I always send out a FLOWSPEC that corresponds to what I have 
installed in my hardware (the clipped value), then this won't happen, 
because the upstream node won't install a reservation larger than requested.

In a unicast scenario, I don't think this can happen, but I'm not 100% 
sure of that.

-- David