Subject: [mpls-tp] Differences in proposed BFD operations for MPLS-TP - OAM framwork, draft-chen-mpls-bfd-enhancement-01 & draft-asm-mpls-tp-bfd-cc-cv-04 ?

From: Lavanya Srivatsa <[email-masked]>
Date: Thu, 27 May 2010 12:39:13 +0530

Hello TP group,

I would like to bring out what I see/understand as differences (or inconsistencies?) in some statements across 3 drafts when using BFD for OAM purposes in an MPLS-TP network.  The 3 drafts I am referring to are the OAM framework, the draft-chen-mpls-bfd-enhancement-01 and the draft-asm-mpls-tp-bfd-cc-cv-04 drafts.

The OAM framework v06 in Section 3.1 states:

"In case of associated bi-directional point-to-point transport

   paths, two independent unidirectional Maintenance Entities are
   defined to independently monitor each direction.

In case of co-routed bi-directional point-to-point transport

   paths, a single bidirectional Maintenance Entity is defined to
   monitor both directions congruently."

When one reads this, it seems clear enough. If this is extended to an OAM protocol such as BFD for monitoring, this would imply using 2 BFD sessions for independently monitoring the 2 independent maintenance entities (forward ME/direction and reverse ME/direction) of the associated bi-directional point-to-point path. Similarly this would imply using 1 single BFD session for monitoring the single maintenance entity (for both the forward and reverse directions commonly) for the co-routed bidirectional point-to-point paths congruently.

Now, draft-chen-mpls-bfd-enhancement-01 states in its Abstract:

"The enhancement halves the BFD sessions over

   those LSPs, and allows a Co-routed Bidirectional LSPs or Associated
   Bidirectional LSPs to be protected and switched as a single entity."

I am assuming that this draft is proposing an "optimization" on top of the behaviour defined in the OAM framework draft to have only 1 BFD session for the associated bidirectional paths/LSPs. Is this understanding correct?

Finally, let's look at draft-asm-mpls-tp-bfd-cc-cv-04 in Section 3.5 which states:

"A single bi-directional BFD session is used for fate

   sharing operation. Two independent BFD sessions are used for
   independent operation.
............

The normal usage is that 1:1 protected paths must use fate sharing,
   and independent operation applies to 1+1 protected paths."

Now this draft seems to contradict both the drafts mentioned above because this seems to define having a single BFD/OAM session or independent BFD/OAM sessions based on the protection architectures of 1:1 and 1+1.

This would then mean that if the 1:1 protected paths are associated bidirectional LSPs they would have a single BFD session. If the 1:1 protected paths are co-routed bidirectional paths, then also they would have a single BFD session.
Similarly, if the 1+1 protected paths are associated bidirectional LSPs they would have independent (2) BFD sessions. If the 1+1 protected paths are co-routed bidirectional LSPs, then also they would have independent (2) BFD sessions.
Is the above interpretation correct?

Another question is that when this draft mentions "1:1 protected paths must use fate sharing", this seems to apply to "1:1 bidirectional protection switching" alone and not to "1:1 unidirectional protection switching". I am saying this because only in bidirectional protection switching the forward and reverse paths/directions fate share - if there is a fault in the forward direction, the reverse direction is also switched onto the protection entity from the working entity.
On similar lines, I feel that when this draft mentions "independent operation applies to 1+1 protected paths", this seems to apply to only "1+1 unidirectional protection switching" alone and not to "1+1 bidirectional protection switching". This is because in unidirectional protection switching, forward path is independent of the reverse path - if there is a fault in the forward direction, only this direction is switched onto the protected entity from the working entity.
Is this understanding correct?

So which is the right way to go here? How many BFD sessions are being proposed for associated bidirectional LSPs and co-routed bidirectional LSPs? How should one go about correlating these various drafts?

If, however I am missing something here, I would appreciate it if someone could enlighten me.

- Lavanya

---

From: Lavanya Srivatsa <[email-masked]>
Date: Mon, 31 May 2010 18:48:17 +0530

Hello TP group & relevant authors,

Could someone please clarify the below?

- Lavanya

________________________________
From: Lavanya Srivatsa
Sent: Thursday, May 27, 2010 12:39 PM
To: MPLS TP
Subject: Differences in proposed BFD operations for MPLS-TP - OAM framwork, draft-chen-mpls-bfd-enhancement-01 & draft-asm-mpls-tp-bfd-cc-cv-04 ?

Hello TP group,

“In case of associated bi-directional point-to-point transport

   paths, a single bidirectional Maintenance Entity is defined to
   monitor both directions congruently.”

“The enhancement halves the BFD sessions over

   those LSPs, and allows a Co-routed Bidirectional LSPs or Associated
   Bidirectional LSPs to be protected and switched as a single entity.”

I am assuming that this draft is proposing an “optimization” on top of the behaviour defined in the OAM framework draft to have only 1 BFD session for the associated bidirectional paths/LSPs. Is this understanding correct?

Finally, let’s look at draft-asm-mpls-tp-bfd-cc-cv-04 in Section 3.5 which states:

“A single bi-directional BFD session is used for fate

…………

The normal usage is that 1:1 protected paths must use fate sharing,
   and independent operation applies to 1+1 protected paths.”

Another question is that when this draft mentions “1:1 protected paths must use fate sharing”, this seems to apply to “1:1 bidirectional protection switching” alone and not to “1:1 unidirectional protection switching”. I am saying this because only in bidirectional protection switching the forward and reverse paths/directions fate share – if there is a fault in the forward direction, the reverse direction is also switched onto the protection entity from the working entity.
On similar lines, I feel that when this draft mentions “independent operation applies to 1+1 protected paths”, this seems to apply to only “1+1 unidirectional protection switching” alone and not to “1+1 bidirectional protection switching”. This is because in unidirectional protection switching, forward path is independent of the reverse path – if there is a fault in the forward direction, only this direction is switched onto the protected entity from the working entity.
Is this understanding correct?

- Lavanya

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 13:14:39 -0700

Hi Lavanya,

Let me try to get back to you today evening or tomorrow about your issues.

Thanks,
Vishwas

On Mon, May 31, 2010 at 6:18 AM, Lavanya Srivatsa
<[email-masked]> wrote:
> Subject: Differences in proposed BFD operations for MPLS-TP - OAM framwork,
> draft-chen-mpls-bfd-enhancement-01 & draft-asm-mpls-tp-bfd-cc-cv-04 ?
>
> Hello TP group,
>
>
>
> I would like to bring out what I see/understand as differences (or
> inconsistencies?) in some statements across 3 drafts when using BFD for OAM
> purposes in an MPLS-TP network.  The 3 drafts I am referring to are the OAM
> framework, the draft-chen-mpls-bfd-enhancement-01 and the
> draft-asm-mpls-tp-bfd-cc-cv-04 drafts.
>
>
>
> When one reads this, it seems clear enough. If this is extended to an OAM
> protocol such as BFD for monitoring, this would imply using 2 BFD sessions
> for independently monitoring the 2 independent maintenance entities (forward
> ME/direction and reverse ME/direction) of the associated bi-directional
> point-to-point path. Similarly this would imply using 1 single BFD session
> for monitoring the single maintenance entity (for both the forward and
> reverse directions commonly) for the co-routed bidirectional point-to-point
> paths congruently.
>
>
>
> I am assuming that this draft is proposing an “optimization” on top of the
> behaviour defined in the OAM framework draft to have only 1 BFD session for
> the associated bidirectional paths/LSPs. Is this understanding correct?
>
>
>
> Now this draft seems to contradict both the drafts mentioned above because
> this seems to define having a single BFD/OAM session or independent BFD/OAM
> sessions based on the protection architectures of 1:1 and 1+1.
>
>
>
> This would then mean that if the 1:1 protected paths are associated
> bidirectional LSPs they would have a single BFD session. If the 1:1
> protected paths are co-routed bidirectional paths, then also they would have
> a single BFD session.
>
> Similarly, if the 1+1 protected paths are associated bidirectional LSPs they
> would have independent (2) BFD sessions. If the 1+1 protected paths are
> co-routed bidirectional LSPs, then also they would have independent (2) BFD
> sessions.
>
> Another question is that when this draft mentions “1:1 protected paths must
> use fate sharing”, this seems to apply to “1:1 bidirectional protection
> switching” alone and not to “1:1 unidirectional protection switching”. I am
> saying this because only in bidirectional protection switching the forward
> and reverse paths/directions fate share – if there is a fault in the forward
> direction, the reverse direction is also switched onto the protection entity
> from the working entity.
>
> On similar lines, I feel that when this draft mentions “independent
> operation applies to 1+1 protected paths”, this seems to apply to only “1+1
> unidirectional protection switching” alone and not to “1+1 bidirectional
> protection switching”. This is because in unidirectional protection
> switching, forward path is independent of the reverse path – if there is a
> fault in the forward direction, only this direction is switched onto the
> protected entity from the working entity.
>
> So which is the right way to go here? How many BFD sessions are being
> proposed for associated bidirectional LSPs and co-routed bidirectional LSPs?
> How should one go about correlating these various drafts?
>
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>

---

From: David Allan I <[email-masked]>
Date: Tue, 1 Jun 2010 01:44:38 -0400

Hi Lavanya:

Apologies for the delay in responding... these are my personal opinions...

IMO the statement in the OAM framework draft that an associated path requires two distinct maintenance entities probably could be revisited. It is not clear to me that we need to impose that restriction. There is no obvious reason to me that this should be so. I beleive the original thinking was that there would be a dissimilar set of MIPs in each direction, but it is not obvious that disimilar MIPs is the correct criteria. BTW we are on new ground here, as I believe associated paths are a new construct..

Hence if the criteria is relaxed such that an associated path can be instrumented by a single ME, a 1:1 "fate sharing" BFD session could instrument for CV both directions of a bi-directional associated path.

As to your other points...

1) A unidirectional path cannot use 1:1 protection, there is no return path to inform the source MEP that it needs to perform the switch.

2) 1+1 bi-directional protection switching can be coordinated or independent. (.e.g on failure in one direction, both directions still switch, or they can maintain completely independent operation).

I hope this helps
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lavanya Srivatsa
Sent: Monday, May 31, 2010 9:18 AM
To: Lavanya Srivatsa; MPLS TP
Subject: Re: [mpls-tp] Differences in proposed BFD operations for MPLS-TP - OAM framwork, draft-chen-mpls-bfd-enhancement-01 & draft-asm-mpls-tp-bfd-cc-cv-04 ?

- Lavanya

Hello TP group,

- Lavanya