The MPLS WG Archive

[dimitri papadimitriou <dpapadimitriou@psg.com>]

hi kireeti,

Kireeti Kompella wrote:
 > Hi Dimitri,
 >
 > On Wed, 12 May 2004 Dimitri.Papadimitriou@alcatel.be wrote:
 >
 >
 >>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

 >>"> 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

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)

thanks,
- dimitri.

 > Kireeti.
 > -------
 >
 > .
 >