The MPLS WG Archive

[Dimitri.Papadimitriou@alcatel.be]

hi, see in-line

>> >>hi, this doesn't mean that they not have to be correctly documented as
>> >>proposed in point 6 of adrian's mail:
>> >
>> > Qu'est ce que tu veux dire?  :-)
>>
>>tout simplement que quel que soit le comportement adopte au niveau de
>>l'implementation il s'agit de le documenter de maniere intelligible et
>>fiable
>  
> C'est bon -- je suis completement d'accord.  Doesn't the one paragraph
> document that I proposed fill this gap?

yes, it is part of the documentation work that needs to be incorporated 
somewhere (- not part of this discussion -) and i would also suggest to 
take into consideration the text proposed by adrian (in draft-farrel- 
section 1.1) and merge it (since they are complementary)

if there is a desire to go a step further with this, it would also make 
sense to also consider the text proposed in sections 8.2.1 and 8.2.4 
that spells out the key difference between PSC and non-PSC networks 
since the former allows for a distinct label to be used for the new LSP 
even though the resources are re-used while with the latter when a 
resource is pre-empted, the labels is re-used by the pre-empting LSP - 
(i.e. for non-PSC the label as well as the resources are pre-empted)

>> >>"> 6. We were looking for a solution that
>> >> >     a. documented more clearly the expected behavior of a 3209-
>> >> >         conformant implementation
>> >
>> > I would support a document that stated ("clarified") in a paragraph
>> > that hard preemption is the de facto standard (BCP) for RSVP-TE.  I
>> > would further support stating that hard preemption is what
>> > implementations of 3473 should do.
>>
>>for the first part i think it is clear that the proposal is to have the
>>commonly applied behaviour documented
> 
> Excellent!
>
>>for the second part a stated in point "c. was extensible to GMPLS
>>without requiring a change to the procedures described in 3473." so
>>the question is upon the interpretation of the Path_State_Removed flag -
>>when the the flag is set upstream nodes interpret that the node
>>forwarding the PathErr has removed the associated state - and to agree
>>on what's additionally required to avoid mis-interpretation when the
>>flag is not set (between soft and hard preemption) note that the
>>current interpretation is as stated in RFC 3473 (Section 4.4)
> 
> The Path_State_Removed flag is orthogonal -- it's just a mechanism to
> remove path state.

ok, just to clarify, this flag has been introduced to allow each node 
along to remove the state, and this because interpretation from 2205 is 
that no action are taken upon PathErr reception by intermediate nodes - 
and the no action is what i wanted to stress out -

> However, the first question is, what is the default preemption
> behaviour for 3473: hard or soft?  

one can say one or the other the issue is what actions are taken, and 
how does it translate for local, upstream, ingress and downstream, 
egress nodes, for both the preempted and the preempting LSP, and here
referring to the first point in the former case the flag should be set 
but in the latter it is not and this is where the interoperability issue 
starts - the document proposed by adrian was imho meant to clarify this 
situation

> I would propose hard, as 3473 builds on 3209.  Then, to go further, 
> we must make sure that the proposed soft preemption mechanism works 
> for 3473 as well.
>
> When you say, "was extensible to GMPLS without 
> requiring a change to the procedures described in 3473", which 
> procedures are you referring to? 3473 does not describe preemption ...  

it doesn't not describe preemption behaviour and this is why draft- 
farrel has been issued to propose a detailed behaviour that smoothly 
integrates the above flag settings and RFC 3473 procedures

> Given that the base is
> hard preemption, soft preemption requires new mechanisms -- hopefully,
> identical for both 3209 and 3473.
> 
> Is that acceptable?

i think it depends whether there are GMPLS implementation that uses the 
un-documented RFC 3209 behaviour when providing PSC LSPs preemption

thanks,
- dimitri.

> Kireeti.
> -------

-- 
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491