The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

On Thu, 13 May 2004, dimitri papadimitriou wrote:

> 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

C'est bon -- je suis completement d'accord.  Doesn't the one paragraph
document that I proposed fill this gap?

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

However, the first question is, what is the default preemption
behaviour for 3473: hard or soft?  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 ...  Given that the base is
hard preemption, soft preemption requires new mechanisms -- hopefully,
identical for both 3209 and 3473.

Is that acceptable?

Kireeti.
-------