Subject: : Restarting sequence numbers in draft-ietf-pwe3-control-pr otocol

From: Richard Sugarman <[email-masked]>
Date: Mon, 12 Jul 2004 11:40:47 +0100

I'd like to suggest a minor amendment to section 5.6.2 Label Mapping
Release.

(This follows up an old conversation previously titled "Section 5.6.2 of
pwe3-control-protocol-07 not
required?").

This amendment

 - makes the sending of LDP Label Request and Label Release messages
optional if there is an alternative way to restart the sequence number
 - makes it clear that receipt and correct handling of these messages is
mandatory.

The aim is to allow implementations to not send LDP Label Requests in
DU/Liberal mode if they wish to support an alternative method of restarting
sequence numbers.  Some existing implementations do not seem to handle LDP
Label Requests gracefully, and so for the sake of interoperability an
alternative method should be allowed.  

Changed lines are marked >> below.

Thanks,

Rich

------------------

New section 5.6.2:

   In situations where the imposition router wants to restart forwarding
>> of packets with sequence number 1, the router MAY 1) Send to
   disposition router a label mapping release, and 2) Send to
   disposition router a label mapping request. 

>> If an alternative method of re-setting the sequence number to 1 is 
>> supported, the sending of a label mapping release and label mapping 
>> request is OPTIONAL.  However, handling receipt these messages as 
>> specified in [1] is always MANDATORY.

   When sequencing is supported, advertisement of a PW label in response 
   to a label mapping request MUST also consider the issues discussed in 
   the section on Label Mapping Advertisements.

Old section 5.6.2:

   In situations where the imposition router wants to restart forwarding
   of packets with sequence number 1, the router shall 1) Send to
   disposition router a label mapping release, and 2) Send to
   disposition router a label mapping request. When sequencing is
   supported, advertisement of a PW label in response to a label mapping
   request MUST also consider the issues discussed in the section on
   Label Mapping Advertisements.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Luca Martini
Sent: 15 June 2004 18:58
To: Richard Sugarman
Cc: [email-masked]'
Subject: Re: [PWE3] Section 5.6.2 of pwe3-control-protocol-07 not
required?

Richard Sugarman wrote:

>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
>  
>
that violates rfc3036 , those implementations need to be fixed.

> - some implementations just do not cope with receipt of a Label Request
(in
>a service impacting way).
>
>  
>
again that is not behavior  that agrees with rfc3036.

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

>[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.
>
>  
>
I agree , it works much better, but we cannot prevent the label 
release/request method as it is part of the rfc3036 already.

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

>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
>
>
>
>
>
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>  
>

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