Subject: Section 5.6.2 of pwe3-control-protocol-07 not required?

From: Richard Sugarman <[email-masked]>
Date: Fri, 11 Jun 2004 16:24:44 +0100

I have some concerns about section 5.6.2 of
draft-ietf-pwe3-control-protocol-07.  I suspect that this section of the
draft has not been widely implemented, but am open to being proved wrong.  

It describes the situation where a router wishes restart forwarding of
packets with sequence number 1.  It suggests

 - sending an LDP Label Release for the PW in question
 - sending a corresponding LDP Label Request.

This seems non-ideal for a couple of reasons.

1) For plain LDP signalling in DU/Liberal mode, most (all?) existing
implementations do not send Label Requests at all.  This has lead to an
undesirable situation where

 - some implementations do not respond to Label Requests
 - some implementations just do not cope with receipt of a Label Request (in
a service impacting way).

Whilst broken implementations should of course be fixed, this situation does
suggest that sending Label Requests can lead to severe interop problems that
will not go away in a hurry.  I suspect that these problems will exist for
PW LSPs as much as for normal LDP LSPs.

2) In the absence of Label Request support, sending a Label Release in
Liberal mode should be avoided as far as possible.  The downstream node that
receives the Label Release will never retry sending the Label Mapping
without operator intervention.  Without a Label Request, the LSP will stay
broken.

[The other places in pwe3-control-protocol that specify sending Label
Release messages, sections 5.2.3 and 5.4.1, do so for specific reasons
reflected in the Label Release status code - these are unexpected
misconfigurations that I believe will _always_ require operator intervention
to resolve].

3) At the Seoul IETF meeting, Luca Martini described an alternative way to
re-set the sequence number that does not involve LDP signalling at all, but
instead utilizes standard sequence number algorithms (see
http://www.ietf.org/proceedings/04mar/index.html, section 2.8.10, under
"Luca - PWE3 sequencing").  This seems like a better way to go forward.

So unless anyone knows of an implementation of section 5.6.2 of
pwe3-control-protocol-07, I would suggest either removing the section
entirely, or instead changing it to comment that re-setting the sequence
number is outside of the scope of the signalling protocol.

Thoughts welcome!

Rich

Richard Sugarman
Network Protocols Group
Data Connection Ltd (DCL)
Tel:  +44 20 8366 1177               
Fax:  +44 20 8363 1039
Email:  mailto:[email-masked]   
Web:  http://www.dataconnection.com

---

From: Luca Martini <[email-masked]>
Date: Tue, 15 Jun 2004 11:57:34 -0600

> - some implementations do not respond to Label Requests
that violates rfc3036 , those implementations need to be fixed.

>a service impacting way).
again that is not behavior  that agrees with rfc3036.

>without operator intervention.  Without a Label Request, the LSP will stay
correct.

>"Luca - PWE3 sequencing").  This seems like a better way to go forward.
I agree , it works much better, but we cannot prevent the label 
release/request method as it is part of the rfc3036 already.

>number is outside of the scope of the signalling protocol.
Actually as far as I can remember most of the implementations of the 
draft-martini version did answer the label request messages.
Since we are almost ready to LC this draft ( I am missing the security 
section which will be posted shortly )
I think that we cannot introduce the methodology that I presented at the 
last PWE3 meeting.
But I still have an item on my list of to do things to write a draft 
about that CW synchronization methodology.
I do not think that removing this section will make things easier, as 
the LDP specification still requires that label request response be 
implemented. So we can still have implementations attempting to use this 
methodology.
What is the issue here ? Do you not want to implement answering label 
request messages ?

Luca

>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>  
>