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 ?

From: Huub van Helvoort <[email-masked]>
Date: Tue, 01 Jun 2010 09:11:49 +0200

Hello Dave,

You wrote:

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

As far as I have understood associated paths are a "normal"
construct in IETF.
Bi-directional (co-routed) paths are a "normal" transport
network construct.

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: David Allan I <[email-masked]>
Date: Tue, 1 Jun 2010 04:05:28 -0400

Hi Huub:

That was exactly my point, from a MEG/MEP/MIP/ME architectural point of view, I do not believe bi-directional associated paths have been considered before... Certainly no such construct exists in Ethernet...although IMO it WOULD be possible with PBB-TE

Hence our statement that there is a separate ME in each direction in the OAM framework draft is open to review and critique...we have a proof point that it may not be a correct classification...

Cheers
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Tuesday, June 01, 2010 3:12 AM
To: [email-masked]
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 ?

Hello Dave,

You wrote:

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

As far as I have understood associated paths are a "normal"
construct in IETF.
Bi-directional (co-routed) paths are a "normal" transport network construct.

Regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Vijayanand C - ERS, HCL Tech" <[email-masked]>
Date: Tue, 1 Jun 2010 13:40:14 +0530

Dave,
Cant  the " 1:1 unidrectional protection switching" be done as described in rfc4872 . The LSP is unidirectional but the signaling/control messages can go in both directions to facilitate this is nt it ( I think this is what Lavanya meant )  , or is there any restriction on this in transport networks ?

Regards
Vijay
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, June 01, 2010 11:15 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 ?

Hi Lavanya:

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 ?
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,

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

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. 
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

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

---

From: David Allan I <[email-masked]>
Date: Tue, 1 Jun 2010 04:18:31 -0400

We do have statements to the effect that if an out of band return path exists it MAY be used.

At the moment unidirectional path procedures are not documented in the draft, what we do awaits a resurrection of the p2mp BFD draft. A future version should clarify that 1:1 bidirectional paths fate share as in the unidirectional case there is nothing to fate share with.  ;-)

cheers
Dave

________________________________
From: Vijayanand C - ERS, HCL Tech [mailto:[email-masked]]
Sent: Tuesday, June 01, 2010 4:10 AM
To: David Allan I; Lavanya Srivatsa; MPLS TP
Cc: Balaji Radhakrishnan - ERS, HCL Tech
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 ?

Dave,

Regards
Vijay

Hi Lavanya:

I hope this helps
Dave

- Lavanya

- Lavanya

DISCLAIMER:

---

From: <[email-masked]>
Date: Tue, 1 Jun 2010 21:18:10 +0100

Every bi-directional PW is a bi-directional associated path in effect.

I think some of the confusion maybe as Dave points out that it accounts for
a case with dissimilar MIPs etc.

I think the other is that typically IETF would specify protocol & node
functionality not how the node actually implements that functionality
internally so it would be upto the implementation to decide whether to use 2
MEPs or 1 MEP.

Ben

On 01/06/2010 09:05, "David Allan I" <[email-masked]> wrote:

> Hi Huub:
> 
> That was exactly my point, from a MEG/MEP/MIP/ME architectural point of view,
> I do not believe bi-directional associated paths have been considered
> before... Certainly no such construct exists in Ethernet...although IMO it
> WOULD be possible with PBB-TE
> 
> Hence our statement that there is a separate ME in each direction in the OAM
> framework draft is open to review and critique...we have a proof point that it
> may not be a correct classification...
> 
> Cheers
> D
> 
> 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 ?
> 
> Hello Dave,
> 
> You wrote:
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 1 Jun 2010 13:50:58 -0700

Dear All,
I think of the co-routed bidirectional MPLS-TP connection as special case of
associated bidirectional connection. If that is correct, then all mechanisms
and behaviors of associated bidirectional connection are applicable to the
co-routed. Reverse is not necessarily true, as mechanisms and behavior,
including BFD-based OAM and CC/CV/RDI in particular, can use awareness of
MIPs of co-routedness of forward and reverse paths. (This is similar, in my
view, to relationship between protection in mesh network and protection in
linear or ring network).
I've used somewhat ambiguous term "MPLS-TP connection" rather than "LSP and
PW" because I don't think that PW has its own characterization as either
co-routed or associated connection in MPLS-TP. I think that it is plausible
that a PW characterization as either co-routed or associated might change as
result of protection switchover.If that is the case, then applicability of
OAM mechanisms and behaviors specific to co-routed and/or associated
bidirectional connections might be an issue.

Regards,
Greg

On Tue, Jun 1, 2010 at 1:18 PM, <[email-masked]> wrote:

> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > Huub van Helvoort