The MPLS WG Archive

[Adrian Farrel <adrian@olddog.co.uk>]

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

Ce commentaire rend le probleme parfaitement. Si on ecrirait les RFC en francais, on
arriverait a une situation presqu' identique. Une minuscule proportion de gens pourraient
les comprendre, mais tous les autres n'auraient aucune idee.

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

Perhaps there is text in draft-farrel-mpls-preemption-01.txt that you could extract to
answer these points. Perhaps you would like to write a new draft to cover them.

We await the result with interest.

Adrian