Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi

From: "[email-masked]" <[email-masked]>
Date: Mon, 2 May 2011 23:54:10 +0200 (CEST)

Forwarding the messate to the MPLS WG mailing list ...

>----Messaggio originale----
>Da: [email-masked]
>Data: 2-mag-2011 23.19
>A: <[email-masked]>
>Ogg: R: [mpls] FW: Poll / Final in draft-cc-cv-rdi
>
>>We would also observe that it is permissable in the specification to 
respond
>>to a poll with a final reply with the session parameters unchanged. So once
>>a session is up a compliant implementation does not actually have to
>>implement on the fly changes to session paramters. The processing of the
>>poll bit can simply be reduced to setting the final bit in the next 
message.
>>This would permit implementations to optimize the UP processing loop.
>
>How this is possible?
>
>Section 6.8.7 of RFC 5880 states that:
>
>   With the exceptions listed in the remainder of this section, a system
>   MUST NOT transmit BFD Control packets at an interval less than the
>   larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less
>   applied jitter (see below).  
>
>If the Poll requires a longer bfd.RemoteMinRxInterval, how can the system 
>ignore the request?
>
>>----Messaggio originale----
>>Da: [email-masked]
>>Data: 20-apr-2011 17.29
>>A: "[email-masked]"<[email-masked]>
>>Cc: "Ross Callon"<[email-masked]>
>>Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi
>>
>>Hi Folks:
>> 
>>We've received a number of comments both formally and informally that the
>>current draft has deviated too far from the base BFD spec and thus loses
>>backward compatibility with existing code bases.  Further, discussions with
>>the BFD WG have indicated we have a potential race condition in the current
>>startup procedures described in draft-cc-cv-rdi.
>> 
>>The issue is the transition to UP state requires confirmation by the peer
>>MEP prior to changing the detection time to the rx-interval x detect mult 
in
>>order to avoid potential flapping. This can result in an implementation
>>effectively needing two UP states (UP forward, UP reverse direction).
>>Otherwise the MEP may time out the reverse direction before seeing an UP
>>state from the peer MEP.
>> 
>>So we can make this implicit in the specification and require BFD changes 
or
>>we can use poll/final discipline on startup as defined in the base
>>specification and make the transition to fully UP and the desired rate both
>>explicit and exposed in the protocol exchange. This would reduce the deltas
>>between the base spec (RFC 5880) and draft CC-CV-RDI.
>> 
>>We would also observe that it is permissable in the specification to 
respond
>>to a poll with a final reply with the session parameters unchanged. So once
>>a session is up a compliant implementation does not actually have to
>>implement on the fly changes to session paramters. The processing of the
>>poll bit can simply be reduced to setting the final bit in the next 
message.
>>This would permit implementations to optimize the UP processing loop.
>> 
>>This is a change of direction from what has been in the draft to date, 
hence
>>we'd look to the WG for comment on this change...
>> 
>>the editors
>>Dave, John and George...
>>
>>
>>_______________________________________________
>>mpls mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mpls
>>
>
>

---

From: David Allan I <[email-masked]>
Date: Tue, 3 May 2011 18:01:01 -0400

Hi Ermino:

I stand corrected. I got lots of private feedback to the effect that current implementations see a "final" response as agreement to the parameters in a poll. Hence changing that semantic is not a good idea.

The alternative discussed was what an implementation does when a poll is not responded to in a resonable amount of time, which can be interpreted as a refusal to change by the far end, or non-implementation of P/F in steady state. At which point an implemention's options are to live with the status quo or take the session down.

Feedback welcome!
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, May 02, 2011 2:54 PM
To: [email-masked]
Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi

respond
>>to a poll with a final reply with the session parameters unchanged. So 
>>once a session is up a compliant implementation does not actually have 
>>to implement on the fly changes to session paramters. The processing 
>>of the poll bit can simply be reduced to setting the final bit in the 
>>next
message.
>If the Poll requires a longer bfd.RemoteMinRxInterval, how can the 
>system ignore the request?
>
>>We've received a number of comments both formally and informally that 
>>the current draft has deviated too far from the base BFD spec and thus 
>>loses backward compatibility with existing code bases.  Further, 
>>discussions with the BFD WG have indicated we have a potential race 
>>condition in the current startup procedures described in draft-cc-cv-rdi.
>> 
>>The issue is the transition to UP state requires confirmation by the 
>>peer MEP prior to changing the detection time to the rx-interval x 
>>detect mult
in
>>order to avoid potential flapping. This can result in an 
>>implementation effectively needing two UP states (UP forward, UP reverse direction).
>>Otherwise the MEP may time out the reverse direction before seeing an 
>>UP state from the peer MEP.
>> 
or
>>specification and make the transition to fully UP and the desired rate 
>>both explicit and exposed in the protocol exchange. This would reduce 
>>the deltas between the base spec (RFC 5880) and draft CC-CV-RDI.
>> 
respond
>>to a poll with a final reply with the session parameters unchanged. So 
>>once a session is up a compliant implementation does not actually have 
>>to implement on the fly changes to session paramters. The processing 
>>of the poll bit can simply be reduced to setting the final bit in the 
>>next
message.
hence

---

From: John E Drake <[email-masked]>
Date: Tue, 3 May 2011 18:41:54 -0700

Hi,

According to RFC 5880, if a node does not receive a Final in response to a Poll, it continues to use the current BFD session parameters and MAY send additional Polls (presumably one per second) in hopes of soliciting a Final.  I don't think we need to say anything more about what the sender of a Poll needs to do.

We need Poll/Final to transition to UP state, so I think what cc-cv-rdi needs to say is that a node which does not support Poll/Final in UP state simply ignores a Poll.

Thanks,

John

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Allan I
> Sent: Tuesday, May 03, 2011 3:01 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi
> 
> Hi Ermino:
> 
> I stand corrected. I got lots of private feedback to the effect that
> current implementations see a "final" response as agreement to the
> parameters in a poll. Hence changing that semantic is not a good idea.
> 
> The alternative discussed was what an implementation does when a poll
> is not responded to in a resonable amount of time, which can be
> interpreted as a refusal to change by the far end, or non-
> implementation of P/F in steady state. At which point an implemention's
> options are to live with the status quo or take the session down.
> 
> Feedback welcome!
> Dave
>

---

From: Jeff Haas <[email-masked]>
Date: Wed, 4 May 2011 08:29:26 -0700

-mpls@ietf

> We need Poll/Final to transition to UP state, so I think what cc-cv-rdi needs to say is that a node which does not support Poll/Final in UP state simply ignores a Poll.

Why do we need P/F to transition to up?  We need it once up to renegotiate our timers.

-- Jeff

>> [email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 4 May 2011 09:10:58 -0700

Jeff,

There was an extended discussion on this topic between Rob Rennison and Dave Allan, the details of which escape me.

Thanks,

John

Sent from my iPhone

> From: Jeff Haas
> Sent: Wednesday, May 04, 2011 8:29 AM
> To: John E Drake
> Cc: David Allan I; [email-masked]; [email-masked]; Nitin
> Bahadur; David Ward
> > According to RFC 5880, if a node does not receive a Final in response
> to a Poll, it continues to use the current BFD session parameters and
> MAY send additional Polls (presumably one per second) in hopes of
> soliciting a Final.  I don't think we need to say anything more about
> what the sender of a Poll needs to do.
> >
> > We need Poll/Final to transition to UP state, so I think what cc-cv-
> rdi needs to say is that a node which does not support Poll/Final in UP
> state simply ignores a Poll.
> 
> >>>> to a poll with a final reply with the session parameters
> unchanged.
> >> So
> >>>> condition in the current startup procedures described in draft-cc-
> cv-
> >> rdi.
> >>>>
> >>>> to a poll with a final reply with the session parameters
> unchanged.
> >> So

---

From: George Swallow <[email-masked]>
Date: Wed, 04 May 2011 15:12:53 -0400

Jeff -

This is my view as well.  You come up slow, use P/F to get to the rate you
want.  After that you can ignore P/F.

...George

On 5/4/11 11:29 AM, "Jeff Haas" <[email-masked]> wrote:

>> > According to RFC 5880, if a node does not receive a Final in response to a
>> Poll, it continues to use the current BFD session parameters and MAY send
>> additional Polls (presumably one per second) in hopes of soliciting a Final.
>> I don't think we need to say anything more about what the sender of a Poll
>> needs to do.
>> >
>> > We need Poll/Final to transition to UP state, so I think what cc-cv-rdi
>> needs to say is that a node which does not support Poll/Final in UP state
>> simply ignores a Poll.
>

---

From: David Allan I <[email-masked]>
Date: Wed, 4 May 2011 15:34:25 -0400

+1

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Wednesday, May 04, 2011 12:13 PM
To: Jeff Haas; John E Drake
Cc: [email-masked]; David Ward
Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi

Jeff -

This is my view as well.  You come up slow, use P/F to get to the rate you want.  After that you can ignore P/F.

...George

-mpls@ietf

-- Jeff

---

From: Jeff Haas <[email-masked]>
Date: Wed, 4 May 2011 13:51:55 -0700

George,

On May 4, 2011, at 3:12 PM, George Swallow wrote:

I'm not a huge fan of generally saying "then you can ignore P/F" but I'm fine with "the application can choose when they respond to polls".

Mostly same thing from a practical implementation standpoint for TP.

-- Jeff

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 5 May 2011 07:31:45 +0300

George, Jeff,
This is exactly the position Rob and I have presented in Maastricht, in Prague and in multiple emil exchanged (off- and on the list):
- Unless the desired rate of your session is 1 pps (or slower), you need P/F to come to the desired rate in a consistent way after the session has been set up.
- If you decide not to manipulate the rate and/or other session parameters on the fly you do not need P/F after the first interaction. But this first interaction cannot be avoided.

I am very happy to hear that the Editors of the cc-cv-rdi draft have decided to move in this direction.

My 2c,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of George Swallow [[email-masked]]
Sent: Wednesday, May 04, 2011 10:12 PM
To: Jeff Haas; John E Drake
Cc: [email-masked]; David Ward
Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi

Jeff -

...George

On 5/4/11 11:29 AM, "Jeff Haas" <[email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>> wrote:

-mpls@ietf

-- Jeff

>> From: [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> [mailto:[email-masked]] On Behalf Of
>> David Allan I
>> To: [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>; [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
>> From: [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> [mailto:[email-masked]] On Behalf Of
>> [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
>> To: [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
>>> Da: [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
>>> Data: 2-mag-2011 23.19
>>> A: <[email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>>
>>>> Da: [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
>>>> Data: 20-apr-2011 17.29
>>>> A: "[email-masked]"<mpls<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>@ietf.org>
>>>> Cc: "Ross Callon"<[email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>>
>>>> [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
>> [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
>> [email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>

_______________________________________________
mpls mailing list
[email-masked]<https://mail.ecitele.com/OWA/UrlBlockedError.aspx>
https://www.ietf.org/mailman/listinfo/mpls

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Robert Rennison <[email-masked]>
Date: Thu, 5 May 2011 12:21:22 -0400

Jeff, 

Looks like folks are finally on the same page wrt the importance of the P/F and its necessity in getting from a slow initial rate  to the desired rate, see my prior email for a detailed description of this. 

I think we are in agreement that once at the non default rate then  support for further/additional rate changes is not necessary. 

Now that we are in agreement we do not want to lose this  subtle understanding.

Hence we should tread very carefully regarding giving any latitude to non support for  P/F.

_If_ any statement is given regarding non support for P/F it will have to be a conditional statement i.e of the form George states  but with additional qualifications "After an initial P/F exchange to go from  an initial rate to the one you  want _then_  an implementation may choose to ignore further rate modification by simple not responding to  subsequent Polls"

If we go with your proposal of "the application can choose when they respond to polls" then we have lost the fact that the response to P/F is necessary in order to get from the slow initial rate to the operators desired rate.  Someone reading this could end up thinking ok, I do not need to implement P/F which then leads to non-interoperable implementations since we cannot go from the slow rate to the desired one.

Cheers

Rob Rennison

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Haas
Sent: Wednesday, May 04, 2011 4:52 PM
To: George Swallow
Cc: David Ward; [email-masked]
Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi

George,

-- Jeff

---

From: Jeff Haas <[email-masked]>
Date: Thu, 5 May 2011 10:05:05 -0700

Rob,

> _If_ any statement is given regarding non support for P/F it will have to be a conditional statement i.e of the form George states  but with additional qualifications "After an initial P/F exchange…

This was what I had meant.

> If we go with your proposal of "the application can choose when they respond to polls" then we have lost the fact that the response to P/F is necessary in order to get from the slow initial rate to…

Not this.

To add a clarification, one possible response to a complete unwanted change of timer parameters is simply to tear down the BFD session.  This completely removes the ambiguity when viewing timer request changes at the protocol level by reacting quickly rather than leaving a pending request unacknowledged.  I suspect that this wouldn't be a preferred mode of operation for the MPLS-TP case though.

-- Jeff

---

From: Robert Rennison <[email-masked]>
Date: Thu, 5 May 2011 13:55:24 -0400

Jeff,

Ok, we are all back in same-page state, so that's good.

Re your clarification saying that an application may bring down a session if the peer tries an unwanted change of parameter; yes you _could_ tear the session down but I do not think this is a "nice" /desired behavior  so do not recommend we go down this path.

Cheers

Rob

-----Original Message-----
From: Jeff Haas [mailto:[email-masked]] 
Sent: Thursday, May 05, 2011 1:05 PM
To: Robert Rennison
Cc: George Swallow; David Ward; [email-masked]
Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi

Rob,

Not this.

-- Jeff