[mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt

[John E Drake <[e-mail]>]

Resent with trailing emails elided.

Sent from my iPhone

From: John E Drake
Sent: Thursday, December 02, 2010 11:21 AM
To: 'Greg Mirsky'
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; [e-mail]; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; [e-mail]; [e-mail]
Subject: CC/CV/RDI nee RE: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt

Hi,

Here is the relevant excerpt from CC/CV/RDI, for those that have not actually read it.

There are two clarifications to the base BFD spec (reference [4]) wrt the behavior of the MinRxInterval = 0.  This is for independent mode *only*, and it may or may not actually be implemented by anyone.

There is a statement that Link Down Indication and Lock Report may be used as inputs to the BFD state machine.  This may be done by mapping them to an existing input to the BFD state machine so the state machine  is not changed in any way.

There is a statement that Poll/Final is currently not used w/ GAL/GACH.  I personally think this is a mistake.

And that's about it.

Thanks,

John

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.

   The transport profile is designed to operate independent of the
   control plane; hence the C bit SHOULD be set.

   This document specifies bi-directional BFD for p2p transport LSPs,
   hence the M bit MUST be clear.

   There are two modes of operation for bi-directional LSPs. One in
   which the session state of both directions of the LSP is coordinated
   and one constructed from BFD sessions in such a way that the two
   directions operate independently. A single bi-directional BFD session
   is used for coordinated operation. Two independent BFD sessions are
   used for independent operation.

   Coordinated operation is as described in [4]. Independent operation
   requires clarification of two aspects of [4]. Independent operation
   is characterized by the setting of MinRxInterval to zero by the MEP
   that is typically the session originator (referred to as the source
   MEP), and there will be a session originator at either end of the bi-
   directional LSP. Each source MEP will have a corresponding sink MEP
   that has been configured to a Tx interval of zero.

   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.

   The first clarification is that when a state change occurs a MEP set
   to a transmit rate of zero sends BFD control messages with a one
   second period on the reverse component until such time that the state
   change is confirmed by the session peer. At this point the MEP set to
   a transmit rate of zero can resume quiescent behavior. This adds
   robustness to all state transitions in the RxInterval=0 case.

   The second is that the originating MEP (the one with a non-zero
   TxInterval) will ignore a DOWN state received from a zero interval
   peer. This means that the zero interval peer will continue to send
   DOWN state messages that include the RDI diagnostic code as the state
   change is never confirmed. This adds robustness to the exchange of
   RDI indication on a uni-directional failure (for both session types
   DOWN with a diagnostic of either control detection period expired or
   neighbor signaled session down offering RDI functionality).

   A further extension to the base specification is that there are
   additional OAM protocol exchanges that act as inputs to the BFD state
   machine; these are the Link Down Indication [5] and the Lock
   Instruct/Lock Report transactions; Lock Report interaction being
   optional.



Sent from my iPhone

From: Greg Mirsky [mailto:[e-mail]]
Sent: Thursday, December 02, 2010 10:53 AM
To: John E Drake
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; [e-mail]; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; [e-mail]; [e-mail]
Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt

To stress that, IMHO, MPLS-TP CC/CV/RDI is neither IP, nor IP/MPLS BFD.
On Thu, Dec 2, 2010 at 10:26 AM, John E Drake <[e-mail]<mailto:[e-mail]>> wrote:
At this level of discussion, what's your point?

Sent from my iPhone

From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, December 02, 2010 10:00 AM
To: John E Drake
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; [e-mail]<mailto:[e-mail]>; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt

Dear John,
I think that MPLS-TP OAM CC/CV/RDI solution is based on BFD. It is not BFD in its entirety but is a subset with some aspects being specific for MPLS-TP and not part of RFC 5880.

Regards,
Greg
On Thu, Dec 2, 2010 at 5:45 AM, John E Drake <[e-mail]<mailto:[e-mail]>> wrote:
That statement is incorrect.  MPLS-TP uses BFD for CC/CV/RDI (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/)


Sent from my iPhone


> -----Original Message-----
> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of
> LEVRAU, LIEVEN (LIEVEN)
> Sent: Thursday, December 02, 2010 5:17 AM
> To: Rajiv Asati (rajiva); Yuanlong Jiang
> Cc: [e-mail]<mailto:[e-mail]>; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad
> hoc team; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-
> mpls-tp-csf-03.txt
>
> provocative statement alert- We should as we are talking about MPLS-TP
> and not about IP network layer.
>