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: Lavanya Srivatsa <[email-masked]>
Date: Tue, 1 Jun 2010 15:06:01 +0530

Dave,

>> Certainly no such construct exists in Ethernet...although IMO it WOULD be possible with PBB-TE
As far as I know, PBB-TE standard specifically mentions that the 2 ESPs that form a p2p TE instance are unidirectional co-routed paths in opposite directions forming a bidirectional TE instance. There is no mention of associated bidirectional paths in PBB-TE.
So I agree with you in the sense that from the MEG/ME/MEP/MIP point of view, associated bidirectional paths have not been considered before.

Replying to your earlier mail here.....:

>> 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.
Using PSC/APS to co-ordinate both ends, by informing source MEP that it needs to switch, 1:1 unidirectional protection should still be possible? However, I do know that while the ITU-T specs G.8031/G.8131 refrain from providing this as a valid protection architecture, the draft-ietf-mpls-tp-linear-protection states this is a valid architecture in Section 4.2.2. So I see a contradiction/conflict here. What is your take on this?

>> 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).
Hmm... I think I disagree. The definition of bidirectional protection switching itself means that if there is a failure in one direction, both directions must switch. So I am not clear on how you say that they can maintain completely independent operation. Could you clarify? Does this not go against the basic definition?

- Lavanya

Date: Tue, 1 Jun 2010 04:05:28 -0400
From: David Allan I <[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 ?
To: "[email-masked]" <[email-masked]>, "[email-masked]"
        <[email-masked]>
Message-ID:
        <[email-masked]>

Content-Type: text/plain; charset="us-ascii"

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:

> 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: [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:

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

---

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

HI Lavanya:

I know PBB-TE explicitly mandates co-routed. I overloaded the term "WOULD" when considering the art of the possible. My bad.

As to your point 1, as I mentioned in my other message the text could be clarified to state that:
	- fate sharing only applies to bi-directional paths
	- if the draft is extended to cover uni-directional paths, 1:1 would be possible if an out of band return path existed.

For point 2, my understanding is that coordinated swithcing for 1+1 is an operator option, but support of this is a mandatory requirement, hence my choice of terms...

I hope this helps
D

-----Original Message-----
From: Lavanya Srivatsa [mailto:[email-masked]] 
Sent: Tuesday, June 01, 2010 5:36 AM
To: MPLS TP; David Allan I; [email-masked]
Subject: Re: 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,

- Lavanya

Hi Huub:

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,

Regards, Huub.

Hi Lavanya:

I hope this helps
Dave

- Lavanya

- Lavanya

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 1 Jun 2010 15:20:56 +0200

Hi,

One comment about one of your statements below:  Section 4.2.2 of
draft-ietf-mpls-tp-linear-protection mentions 1:1 unidirectional
"switching" as an option - this needs to be differentiated from 1:1
unidirectional "protection".  The former refers to a possibility of
switching only a single direction of bidirectional path, but it is still
protecting a bidirectional path, whereas the latter would be protecting
a unidirectional path which is not required for MPLS-TP (see RFC5654
Requirement 67c.) and therefore not covered by this draft!

Best Regards,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Lavanya Srivatsa
Sent: Tuesday, June 01, 2010 12:36
To: MPLS TP; [email-masked]; [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 ?

Dave,

>> Certainly no such construct exists in Ethernet...although IMO it
WOULD be possible with PBB-TE
As far as I know, PBB-TE standard specifically mentions that the 2 ESPs
that form a p2p TE instance are unidirectional co-routed paths in
opposite directions forming a bidirectional TE instance. There is no
mention of associated bidirectional paths in PBB-TE.
So I agree with you in the sense that from the MEG/ME/MEP/MIP point of
view, associated bidirectional paths have not been considered before.

Replying to your earlier mail here.....:

>> 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.
Using PSC/APS to co-ordinate both ends, by informing source MEP that it
needs to switch, 1:1 unidirectional protection should still be possible?
However, I do know that while the ITU-T specs G.8031/G.8131 refrain from
providing this as a valid protection architecture, the
draft-ietf-mpls-tp-linear-protection states this is a valid architecture
in Section 4.2.2. So I see a contradiction/conflict here. What is your
take on this?

>> 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).
Hmm... I think I disagree. The definition of bidirectional protection
switching itself means that if there is a failure in one direction, both
directions must switch. So I am not clear on how you say that they can
maintain completely independent operation. Could you clarify? Does this
not go against the basic definition?

- Lavanya

<[email-masked].
se>

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,

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.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Allan I

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.

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,

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

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?

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

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
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Tue, 1 Jun 2010 14:49:13 +0100

Further point...

Co-routing and true fate sharing in layer N is only possible IFF all
layer networks below layer N right to the duct network are also
co-routed....one might assume one has co-routing at layer N but if one
cannot see/control all routings in lower layer networks then co-routing
at layer N cannot be guaranteed.

regards, neil  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Allan I
> Sent: 01 June 2010 10:44
> To: Lavanya Srivatsa; MPLS TP; [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 ?
> 
> HI Lavanya:
> 
> I know PBB-TE explicitly mandates co-routed. I overloaded the 
> term "WOULD" when considering the art of the possible. My bad.
> 
> 	- if the draft is extended to cover uni-directional 
> paths, 1:1 would be possible if an out of band return path existed.
> 
> For point 2, my understanding is that coordinated swithcing 
> for 1+1 is an operator option, but support of this is a 
> mandatory requirement, hence my choice of terms...
> 
> I hope this helps
> D
> 
> Subject: Re: Differences in proposed BFD operations for 
> As far as I know, PBB-TE standard specifically mentions that 
> the 2 ESPs that form a p2p TE instance are unidirectional 
> co-routed paths in opposite directions forming a 
> bidirectional TE instance. There is no mention of associated 
> bidirectional paths in PBB-TE.
> So I agree with you in the sense that from the MEG/ME/MEP/MIP 
> point of view, associated bidirectional paths have not been 
> considered before.
> 
> >> 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.
> Using PSC/APS to co-ordinate both ends, by informing source 
> MEP that it needs to switch, 1:1 unidirectional protection 
> should still be possible? However, I do know that while the 
> ITU-T specs G.8031/G.8131 refrain from providing this as a 
> valid protection architecture, the 
> draft-ietf-mpls-tp-linear-protection states this is a valid 
> architecture in Section 4.2.2. So I see a 
> contradiction/conflict here. What is your take on this?
> 
> >> 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).
> Hmm... I think I disagree. The definition of bidirectional 
> protection switching itself means that if there is a failure 
> in one direction, both directions must switch. So I am not 
> clear on how you say that they can maintain completely 
> independent operation. Could you clarify? Does this not go 
> against the basic definition?
> 
> - Lavanya
> 
> 
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Allan I
> 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 
> 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.
> 
> 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
> 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 ?
> Subject: Differences in proposed BFD operations for MPLS-TP - 
> OAM framwork, draft-chen-mpls-bfd-enhancement-01 & 
> 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 
> 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?
> 
> "DISCLAIMER: This message is proprietary to Aricent and is 
> intended solely for the use of the individual to whom it is 
> addressed. It may contain privileged or confidential 
> information and should not be circulated or used for any 
> purpose other than for what it is intended. If you have 
> received this message in error, please notify the originator 
> immediately. If you are not the intended recipient, you are 
> notified that you are strictly prohibited from using, 
> copying, altering, or disclosing the contents of this 
> message. Aricent accepts no responsibility for loss or damage 
> arising from the use of the information transmitted by this 
> email including damage from virus."

---

From: Lavanya Srivatsa <[email-masked]>
Date: Wed, 2 Jun 2010 23:02:30 +0530

Yaacov,

Now you have me totally confused :-(

This concept of "unidirectional switching" for bidirectional path as opposed to "unidirectional protection" seems new to me....
It is not clear what you mean by "switching only a single direction of bidirectional path but still protecting a bidirectional path" and how this is different from "protecting a unidirectional path". Yes, I am aware of 67c in RFC 5654 and that is why I was trying to confirm that the asm-cc-cv draft does not refer to 1:1 unidirectional protection switching in my earlier mails.

Still, I think that "switching a single direction" is what unidirectional protection switching is all about. Can you clarify why you are calling it unidirectional "switching"?
Also, if one switches only a single direction upon a unidirectional fault, and does not switch the other direction, how could this be "still protecting a bidirectional path"? If we were protecting a bidirectional path, we would be switching both directions, wouldn't we? 

According to me - "Switching traffic" is the means of providing "protection" !!

Moreoever, section 4.2.2 has a heading of "Protection Type (PT)" and it has one value pertaining to "00: 1:1 unidirectional switching". 
I am able to interpret this only as talking about 1:1 unidirectional protection switching.

On the same lines, are you saying that 1:1 bidirectional "switching" is different from 1:1 bidirectional "protection"?

- Lavanya

________________________________________
From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Tuesday, June 01, 2010 6:50 PM
To: Lavanya Srivatsa; MPLS TP; [email-masked]; [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 ?

Hi,

Best Regards,
yaacov

-----Original Message-----

Dave,

- Lavanya

Hi Huub:

Cheers
D

-----Original Message-----

Hello Dave,

opinions...

Regards, Huub.

Hi Lavanya:

I hope this helps
Dave

- Lavanya

- Lavanya

---

From: Lavanya Srivatsa <[email-masked]>
Date: Wed, 2 Jun 2010 23:19:33 +0530

Dave,

     >>   - fate sharing only applies to bi-directional paths
[LS] Ok. Will wait for next version of this draft to correct this.

     >>  - if the draft is extended to cover uni-directional paths, 1:1 would be possible if an out of band return path existed.
[LS] Ok, accepted, return path will help in co-ordinating the protection switch to the remote node. If so, 1:1 unidirectional PS should be possible. However, I am confused with what Yacoov had replied. Am waiting for clarification from him on the difference between "1:1 unidirectional switching" and "1:1 unidirectional protection".

>> For point 2, my understanding is that coordinated swithcing for 1+1 is an operator option, but support of this is a mandatory requirement, hence my choice of terms...
[LS] By "co-ordinated switching for 1+1" do you mean 1+1 bidirectional protection switching? According to me 1+1 bidirectional PS is co-ordinated, 1+1 unidirectional PS is independent. 
Moreoever are you referring to any document/draft/requirement in specific when you say that "support of this is mandatory requirement"? If so, which one?

Thanks
- Lavanya

________________________________________
From: David Allan I [[email-masked]]
Sent: Tuesday, June 01, 2010 3:13 PM
To: Lavanya Srivatsa; MPLS TP; [email-masked]
Subject: RE: 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:

I hope this helps
D

-----Original Message-----
From: Lavanya Srivatsa [mailto:[email-masked]]
Sent: Tuesday, June 01, 2010 5:36 AM
To: MPLS TP; David Allan I; [email-masked]
Subject: Re: 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,

- Lavanya

Hi Huub:

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,

Regards, Huub.

Hi Lavanya:

I hope this helps
Dave

- Lavanya

- Lavanya

---

From: Lavanya Srivatsa <[email-masked]>
Date: Wed, 2 Jun 2010 23:20:09 +0530

Neil, I agree with your point below.

________________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, June 01, 2010 7:19 PM
To: [email-masked]; Lavanya Srivatsa; MPLS TP; [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 ?

Further point...

regards, neil

> associated path

---

From: David Allan I <[email-masked]>
Date: Thu, 3 Jun 2010 04:35:09 -0400

Hi Lavanya:

As to your latter point....

1+1 protected bi-directional paths can operate as coordinated or independent protection switching. IMO some operators prefer 1+1 bi-directional to be coordinated as it means some classes of fault repair do not introduce an extra "hit" but my understanding is that coordinated is not mandatory...

One thing that is clear in the document is that the term fate-sharing introduces confusion, in the future we'll replace with coordinated so that any confusion between how paths are routed, and how PS coordnation behaves can be clearly disambiguated.

Hope this helps
D

-----Original Message-----
From: Lavanya Srivatsa [mailto:[email-masked]]
Sent: Wednesday, June 02, 2010 1:50 PM
To: David Allan I; MPLS TP; [email-masked]; Lavanya Srivatsa
Subject: RE: 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,

Thanks
- Lavanya

HI Lavanya:

I hope this helps
D

-----Original Message-----
From: Lavanya Srivatsa [mailto:[email-masked]]
Sent: Tuesday, June 01, 2010 5:36 AM
To: MPLS TP; David Allan I; [email-masked]
Subject: Re: 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,

- Lavanya

Hi Huub:

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,

Regards, Huub.

Hi Lavanya:

I hope this helps
Dave

- Lavanya

- Lavanya

---

From: "Vijayanand C - ERS, HCL Tech" <[email-masked]>
Date: Thu, 3 Jun 2010 14:57:38 +0530

Hello all,
A query regarding PSC behaviour.

In RFC5654 req 90 says inband OAM must support PSC and run on protection resources. As per draft-ietf-mpls-tp-linear-protection PSC control packets should be sent over recovery path only(section 4.1). PSC msgs indicating protection path failure may not reach the other end(section 4.3.4) , in which case PSC will not switch to unavailable state and will erroneously indicate protection as available. How is this resolved ? In this case, will the PSC supported by MPLS-tp control plane ( req 89) come into play for this path ?.

 Will the PSC as defined in req 89 of rfc5654 be applied to all paths in addition to PSC using recovery paths as defined in req. 90 for inband OAM or is it an option or not applied at all

Thanks in advance.
Regards
Vijay

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: Fri, 4 Jun 2010 04:48:05 -0400

HI Vijay:

Not my draft, but the question was directed to me so...

My understanding is that CC/CV on the protection path owns the job of determining availability. 

SO you should know prior to attempting PSC for a working path failure if the protection path is down. PSC on the protection path should not be the first line of fault detection/management...

Sorry I did not quite understand your second question. Can you rephrase..?

Hope this helps
D

-----Original Message-----
From: Vijayanand C - ERS, HCL Tech [mailto:[email-masked]] 
Sent: Thursday, June 03, 2010 5:28 AM
To: David Allan I; MPLS TP
Cc: Balaji Radhakrishnan - ERS, HCL Tech
Subject: PSC behaviour

Hello all,

Thanks in advance.
Regards
Vijay

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: "Vijayanand C - ERS, HCL Tech" <[email-masked]>
Date: Fri, 4 Jun 2010 15:45:30 +0530

Hi Dave,
Thanks for the reply.

So, the local OAM will detect and indicate unavailability of protection path and trigger the PSC logic( as per architecture in section 3.2) to change the state in this case ?  I asked this since it was not stated in section 4.3.4 as to how PSC will change the state when protection path becomes unavailable. Perhaps this should have been stated clearly in the draft.

The seconds question is, as per req 89 of rfc5654,the PSC maintained by the control plane may run on resources other than protection resources. whereas in req 90 it is stated that the PSC  supported by in-band OAM must run on protection resources. As per draft-ietf-mpls-tp-linear-protection PSC control packets should be sent over recovery path only(section 4.1). So I don't understand how the PSC maintained by control plane is applied.

Thanks in advance.
Regards
Vijay

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Friday, June 04, 2010 2:18 PM
To: Vijayanand C - ERS, HCL Tech; MPLS TP
Cc: Balaji Radhakrishnan - ERS, HCL Tech
Subject: RE: PSC behaviour

HI Vijay:

Hope this helps
D

-----Original Message-----
From: Vijayanand C - ERS, HCL Tech [mailto:[email-masked]] 
Sent: Thursday, June 03, 2010 5:28 AM
To: David Allan I; MPLS TP
Cc: Balaji Radhakrishnan - ERS, HCL Tech
Subject: PSC behaviour

Hello all,

Thanks in advance.
Regards
Vijay

DISCLAIMER:

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 07 Jun 2010 17:53:21 -0400

Vijay,

There are two (implied) characteristics of OAM.

  1.  All OAM used in monitoring must be fate sharing with the payload
      (data plane).  This includes CC/CV, LM, DM, etc.

  2.  All OAM used for response of outage must be reliable with
      respect to the fault that it is protecting.  This includes
      anything related to PSC.

RFC5654 req 90 item B addresses the second (implied) requirement for
inband PSC OAM.

There is no mention of an out of band PSC.  Note that if PSC OAM is
out of band, then it would have to be over a reliable sublayer or
layer.  Substituting "protected" for "reliable" in the prior sentence
creates a chicken-and-egg problem, which may be why OOB is omitted.

Note that the control plane is not manditory but if the control plane
is implemented and is in use it may support PSC (req 89), therefore
allowing PSC OAM to be disabled in such deployments.  If PSC OAM is
used instead of CP PSC and the OAM is inband, then req 90 applies.

As I understand it equipment support for PAC OAM is required and any
support for CP is optional.  CP PSC already exists as GMPLS protection
mechanisms.  In practice (though this is speculative), whether part of
TP or not, FRR is likely to continue to be used even in networks that
are using TP and are using proactive OAM for monitoring purposes (such
as verifying SLA conformance).  Regardless, PSC OAM (and therefore
RFC5654 req 90) is required and CP is optional and RFC5654 req 89 is
conoptional on CP.

Curtis

In message <[email-masked]>
"Vijayanand C - ERS, HCL Tech" writes:

Hello all,

In RFC5654 req 90 says inband OAM must support PSC and run on
protection resources. As per draft-ietf-mpls-tp-linear-protection PSC
control packets should be sent over recovery path only(section
4.1). PSC msgs indicating protection path failure may not reach the
other end(section 4.3.4) , in which case PSC will not switch to
unavailable state and will erroneously indicate protection as
available. How is this resolved ? In this case, will the PSC supported
by MPLS-tp control plane ( req 89) come into play for this path ?.

Will the PSC as defined in req 89 of rfc5654 be applied to all paths
in addition to PSC using recovery paths as defined in req. 90 for
inband OAM or is it an option or not applied at all

Thanks in advance.
Regards
Vijay

DISCLAIMER:

---

From: Lavanya Srivatsa <[email-masked]>
Date: Tue, 8 Jun 2010 13:06:39 +0530

Dave,

Apologies for the delay in responding..... have snipped some initial mails....

>> 1+1 protected bi-directional paths can operate as coordinated or independent protection >>switching. IMO some operators prefer 1+1 bi-directional to be coordinated as it means some >>classes of fault repair do not introduce an extra "hit" but my understanding is that >>coordinated is not mandatory...

I think maybe I was not clear on what I was trying to communicate. Let me explain. I am getting into some basics and a long mail maybe, apologize, but just hoping to converge faster...

1) Paths can be (a) unidirectional (b) bidirectional (either associated or co-routed)

Protection Switching (PS) can be (a) unidirectional PS - meaning that fault in one direction causes only the traffic of that direction to switch from working to protection (b) bidirectional PS - meaning that fault in one direction causes both directions to switch from working to protection

2) So mapping your terminology to mine would mean:
Unidirectional PS = Independent PS
Bidirectional PS = Fate Shared (or) Co-ordinated PS 

3) Unidirectional paths can be provided with Unidirectional/Independent PS.
Bidirectional paths can be provided with either Unidirectional/Independent PS or Bidirectional/Fate-Shared/Co-ordinated PS.

4) The valid protection switching (PS) architecture types would be (as per the linear-protection draft):
1+1 unidirectional PS
1+1 bidirectional PS
1:1 bidirectional PS
1:1 unidirectional PS - iff there is a return path and PSC messages can be exchanged between the 2 ends of the protection domain.
I am still awaiting a response from Yaacov to confirm the above architecture types for protection switching.

Would you agree with all of the 4  points mentioned above?

With this understanding, I agree to your statements (that I have pasted above). Bidirectional paths can operate as coordinated or independent.

However, this is not the doubt that I am trying to get clarified.

My doubt is this - the cc-cv draft mentions (and sorry, I am quoting these statements again) -
"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."

What does "1:1 protected paths must use fate sharing" mean? According to me, any protected path, when used in the 1:1 architecture, must use fate sharing when the intent is to perform bidirectional PS. If the intent is to perform unidirectional PS, the paths can operate independently.
I think you have clarified that this ought to be rephrased as "fate sharing for protected paths when using 1:1 bidirectional protection switching", so I will leave it at that.

Now, for the "1+1 protected paths must have independent operation" - according to me, any protected path, when used in the 1+1 architecture, must have independent operation when the intent is to perform unidirectional PS. If the intent is to perform bidirectional PS, then paths should fate-share or operate in a co-ordinated manner.
So I feel that a rephrase in the draft is required for 1+1 too. Suggestion - "independent operation for protected paths when using 1+1 unidirectional protection switching".

This is what I am trying to get clarified from you/authors of the cc-cv draft.

- Lavanya

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Thursday, June 03, 2010 2:05 PM
To: Lavanya Srivatsa; MPLS TP; [email-masked]
Subject: RE: 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:

Hope this helps
D

-----Original Message-----
From: Lavanya Srivatsa [mailto:[email-masked]]
Sent: Wednesday, June 02, 2010 1:50 PM
To: David Allan I; MPLS TP; [email-masked]; Lavanya Srivatsa
Subject: RE: 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,

Thanks
- Lavanya

---

From: Lavanya Srivatsa <[email-masked]>
Date: Wed, 9 Jun 2010 17:16:45 +0530

Yaacov,

Could be please clarify?

- Lavanya

-----Original Message-----
From: Lavanya Srivatsa 
Sent: Wednesday, June 02, 2010 11:03 PM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); MPLS TP; [email-masked]; [email-masked]
Cc: Lavanya Srivatsa
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 ?

Yaacov,

- Lavanya

Hi,

Best Regards,
yaacov

-----Original Message-----

Dave,

- Lavanya

Hi Huub:

Cheers
D

-----Original Message-----

Hello Dave,

opinions...

Regards, Huub.

Hi Lavanya:

I hope this helps
Dave

- Lavanya

- Lavanya

---

From: "Vijayanand C - ERS, HCL Tech" <[email-masked]>
Date: Thu, 10 Jun 2010 18:51:41 +0530

Curtis,
Thanks for the detailed reply.

Perhaps it needs to be qualified in the documents that the PSC as defined in req 89 for CP need not be the PSC defined in draft-ietf-mpls-tp-linear-protection.

Another clarification in the list , in section 3.2 of draft-ietf-mpls-tp-linear-protection, its not clear how the global request logic would prioritise the requests from PSC messages versus that from the OAM module, especially in cases ( like that in section 4.3.4 ?) where there is a chance that PSC messages are not consistent with the OAM module.

Regards
Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 3:23 AM
To: Vijayanand C - ERS, HCL Tech
Cc: 'David Allan I'; MPLS TP
Subject: Re: [mpls-tp] PSC behaviour 

Vijay,

Curtis

Hello all,

Thanks in advance.
Regards
Vijay

DISCLAIMER:

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Jun 2010 10:45:11 -0400

In message <[email-masked]>
"Vijayanand C - ERS, HCL Tech" writes:
> Perhaps it needs to be qualified in the documents that the PSC as
> defined in req 89 for CP need not be the PSC defined in
> draft-ietf-mpls-tp-linear-protection.
>  
> Another clarification in the list , in section 3.2 of
> draft-ietf-mpls-tp-linear-protection, its not clear how the global
> request logic would prioritise the requests from PSC messages versus
> that from the OAM module, especially in cases ( like that in section
> 4.3.4 ?) where there is a chance that PSC messages are not consistent
> with the OAM module.
>  
> Regards
> Vijay

Vijay,

Current practice is to take any indication that an LSP is down as
sufficient even in the absense of other indications.  It seems to make
most sense to have one channel for PSC messages, either a control
plane protocol or OAM messages, and not multiple channels, however if
there were multiple, any indication that the working path is down
should be regarded as sufficient to move traffic to the protection
path.

BTW- If the protection is also indicated as down, then a further
fallback may be available or reroute may be required (if there is a
control plane to use for reroute) or its anyone's guess as to which
LSP has a greater chance of being up.  Current thinking seems to be to
send on neither path and send OAM at reduced rate until the LSP (or
PW) comes back up.

Curtis