Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Apr 2011 19:08:43 +0800

All,

this working group last call has ended!

I've not seen any comments!

/Loa

On 2011-03-30 23:06, Loa Andersson wrote:
> All,
>
> someone = possibly me - mixed the mail addresses up. This was intended
> for the bfd working group! Though comments from the routing directorate
> would be welcome!
>
> /Loa
>
> On 2011-03-30 17:00, Loa Andersson wrote:
>> BFD working group,
>>
>> This is to start a 19 days BFD working group last on an mpls wg draft;
>>
>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi-03.txt
>>
>> the draft was recently wg last called in the mpls wg, but the wg chairs
>> of both groups has agreed that this draft should also be last called in
>> the bfd working group.
>>
>> The document is part of the ongoing mpls-tp project.
>>
>> Please send your comments to the [email-masked] mailing list.
>>
>> If your are not subscribed to the mpls wg list, please send to the
>> bfd wg mailing list ([email-masked])
>>
>> This working group last call ends April 11.
>>
>>
>> Loa George Ross Jeff and Dave
>>
>> mpls and bfd working group chairs
>>
>

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Apr 2011 01:18:27 +0000

As was discussed with Loa off-list, I didn't prioritize my reply high enough
since I was counting 19 days from mail list publication and had ignored the
embedded date.  Here are my comments upon reviewing
draft-ietf-mpls-tp-cc-cv-rdi-03:

: 3.5. BFD Profile for MPLS-TP
: 
: 
:    BFD MUST operate in asynchronous mode. In this mode, the BFD Control
:    packets are periodically sent at configurable time rate. This rate is
:    typically a fixed value for the lifetime of the session. In the rare
:    circumstance where an operator has a reason to change session
:    parameters, the session MUST be moved to the ADMIN DOWN state.
:    Poll/final discipline can only used for VCCV and UDP/IP encapsulated
:    BFD.

As was discussed at IETF 80 with the authors, the lack of a poll sequence is
the single biggest obstacle to interoperability with standard BFD version 1.
As was explained to me, the motivation to avoid poll sequences included
several factors, but the primary one was the desire to avoid having to deal
with the full gamut of possible timers that may be offered.

The suggested behavior that addresses the concern of supporting only
specific well accepted timers is the observation that in response to a poll
sequence containing unacceptable timer values, it is acceptable for the
receiver of the poll sequence to simply take the session into the Down
state.  With the addition of the "configuration error" code point, this
will hopefully be an acceptable solution.

:    The base spec is unclear on aspects of how a MEP with a BFD transmit
:    rate set to zero behaves. One interpretation is that no periodic
:    messages on the reverse component of the bi-directional LSP originate
:    with that MEP, it will only originate messages on a state change.

This particular spect of BFD is unclear since the expected case where
transmit behavior is totally suppressed while in the Up state is done via
Demand mode.  I would suggest that Demand mode be used for the sink MEP.

: 3.5.1. Session initiation
: 
: 
:    In all scenarios a BFD session starts with both ends in the DOWN
:    state. DOWN state messages exchanged include the desired Tx and Rx
:    rates for the session. If a node cannot support the Min Tx rate
:    desired by a peer MEP it does not transition from down to the INIT
:    state and sends a diagnostic code of configuration error (to be
:    assigned by IANA) indicating that the requested Tx rate cannot be
:    supported.

As discussed above, a poll sequence should be used to adjust the timers.
The primay impact on this section is that it's deleted and normal BFD
behavior of session initialization with 1 second timers is used.

: 3.5.4.2. Exit from a session mis-configuration defect
: 
: 
:    Exit from a misconfiguration defect occurs when two consecutive CC or
:    CV frames have been received with the expected M bit setting.

It may not have been the intention of this section, but this seems to
suggest the M-bit is being used for misconfiguration signaling.  If the
authors take the suggestion of keeping the polling sequence but permitting
the use of forcing a session Down with the configuration error Diag code,
this section may require some rework.

: 3.5.5. State machines

This section has the items of most concern to me.  I believe other points
have been raised off-list about this section but I don't have the relevant
messages.  Here are my observations:

The coordinated session state machine is effectively the base BFD state
machine with additional inputs that can force transition into the Down
state.  These are all fine and do not impact BFD version 1 compatibility.

The source MEP state machine does not transition out of the Up state without
receiving an Admin Down event.  If the suggestion of Demand mode above is
taken, the behavior is effectively the same as if the replies from the sink
MEP have been lost.  In other words, the source MEP continues to hammer BFD
control messages on the wire at the negotiated Tx rate.  As long as the Tx
rate is negotiated via a poll sequence, it should never be faced with a BFD
peer that wasn't capable of absorbing that level of traffic.  Thus, in my
opinion, while this is a violation of the BFD v1 state machine, it's not a
critical fault.

:    The sink MEP state machine (for which the transmit interval has been
:    set to zero) is modified to:
: 
:    1) Permit direct transition from DOWN to UP once the session has been
:    initialized. With the exception of via the ADMIN DOWN state, the
:    source MEP will never transition from the UP state, hence in normal
:    unidirectional fault scenarios will never transition to the INIT
:    state.

Again, I'd suggest that demand mode be used here.

The state machine change is also incompatible with the base BFD v1 state
machine.  Unlike the source MEP state machine which can be observed to be
behaving "correctly" if one pretends that messages are being lost in demand
mode, a BFD v1 state machine can't successfully interoperate with a sink MEP
state machine after the first fault without an intervening AdminDown event.

I would suggest some strong caveat in the text about how independent
session state machines MUST NOT face a BFD v1 compliant state machine.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 19 Apr 2011 12:19:59 -0700

Dear Jeff,
I've got very interested by your suggestion to use Demand mode in
Independent mode of operating MPLS-TP CC/CV.
If I understand correctly, it would be the Source that is in Demand mode and
sets its D bit up after the session reaches the Up state. The Sink, remote
system, would not enter Demand mode but will have to not to send periodic
control messages to Source according to Section 6.6 RFC 5880. That is the
same effect as Source setting MinRxInterval to zero as described in the
draft-ietf-mpls-tp-cc-cv-rdi-03 now. The behavior of the system with
assymetric use of the Demand mode is not defined by RFC 5880:
" Resolving the issue of one system requesting Demand mode while the other
requires continuous bidirectional connectivity verification is outside the
scope of this specification."
Is the purpose of the Demand mode in Independent mode of monitoring
bi-directional associated MPLS-TP LSP to suppress periodic control messages
from Sink to improve compatibility with RFC 5880? But RFC is vague on how
such asymmetric mode operates thus interoperability might be an issue here
too.

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Apr 2011 19:54:32 +0000

Greg,

On Tue, Apr 19, 2011 at 12:19:59PM -0700, Greg Mirsky wrote:
> draft-ietf-mpls-tp-cc-cv-rdi-03 now.

Right.  This places the desired behavior more into the general expected
design of the protocol rather than requiring more special cases.

>  The behavior of the system with

In the context of the typical BFD behavior, Demand mode is expected when
bi-directional connectivity is being verified by some means outside of the
BFD async mechanism.  One would normally expect such a mechanism to be
symmetrical.  MPLS-TP CC-CV is a case where that's not true.

> such asymmetric mode operates thus interoperability might be an issue here

I think it's less vague than "this isn't what the protocol was typically
designed for".  The non-independent mode of BFD functions as a normal BFD
speaker would be expected to function.  Independent mode instead uses two
pairs of BFD state machines to measure each side of a unidirectional LSP's
connectivity. (Presuming I got the use case correct.)

The purpose of my suggestions is primarily to look for ways supported within
the base BFD protocol specification to implement MPLS-TP CC-CV desired
behaviors with minimal changes.  I think with demand mode and supporting
poll sequences that this gets us most of the way there.

-- Jeff

---

From: George Swallow <[email-masked]>
Date: Wed, 20 Apr 2011 16:23:45 -0400

Adding Dave Allen and John Drake to the thread.

...George

---

From: John E Drake <[email-masked]>
Date: Wed, 20 Apr 2011 14:07:46 -0700

Hi,

I had sent an email to Jeff asking about his suggestion to use Demand to support Independent Mode and telling him about our new proposal for supporting P/F.

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2011 1:24 PM
> To: Jeffrey Haas; Greg Mirsky; David Allan; John E Drake
> Cc: Jeff Haas; David Ward; Ross Callon; [email-masked]
> Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-
> tp-cc-cv-rdi-03
>