Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

From: Lavanya Srivatsa <[email-masked]>
Date: Mon, 14 Jun 2010 00:30:31 +0530

I am with Mach on both counts - 

(1) IMHO too, explicit null label distribution and PHP needs to be sorted out. If an OAM packet is received without the label, demultiplexing would become a problem. Even if the OAM packet contains discriminator values, if the packet does not carry the label, determining the LSP and therefore the destination MEP would be difficult in order to do CV (since only the source MEP TLV will be carried in the packet). Therefore I think the OAM context will be lost in case of PHP.

BTW, can someone please clarify as to why the data plane draft introduces the "disabled by default" for PHP? I remember this point was raised by Curtis Villamizar earlier (Wed, 14 Apr 2010 ) but apart from someone suggesting that this gave the operator a choice, I dont seem to remember a concrete reason for this. IMHO, it should be "disabled at all times" for MPLS-TP networks.

(2) Is there any draft which defines the "unidirectional " and "bidirectional" BFD sessions? I share Mach's confusion on this. Since the BFD state machine changes state based on what it receives from the peer node during session establishment, I think that a return path is necessary for the BFD session to be set up.
Also, I am not sure why in order to perform unidirectional protection, a bidirectional BFD session need not/can not be used. I think even if we need to do unidirectional protection, all we need are the for 2 directions to operate independently, so that a fault in one direction of the path causes only that direction of the path to be moved on the protection/recovery path. So IMHO the number of sessions or unidirectional/bidirectional BFD sessions should be independent of the protection mechanism.

- Lavanya

Date: Sat, 12 Jun 2010 10:22:00 +0800
From: Mach Chen <[email-masked]>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
To: Greg Mirsky <[email-masked]>, Shahram Davari
        <[email-masked]>
Cc: Mukund Mani <[email-masked]>, [email-masked]
Message-ID: <3851F6A35FA14D64B6985853F2F12CA5@m55527c>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1;
        reply-type=original

Hi Greg and Shahram,

Thanks for your response!

I have a little bit confusion about unidirectional and bidirectional BFD
session (and I failed to find where have these definitions). Do you mean
that unidirectional BFD session only has forward path and no return path? My
understanding about a BFD session is that it should have both forward and
return paths, and if this is true and assume to setup separate BFD session
for each direction of an associated bidirectional LSP, then the PEs of the
LSP will failed to demultiplex the BFD sessions.

Best regards,
Mach

--------------------------------------------------
From: "Greg Mirsky" <[email-masked]>
Sent: Saturday, June 12, 2010 3:02 AM
To: "Shahram Davari" <[email-masked]>
Cc: "Mach Chen" <[email-masked]>; "Mukund Mani" <[email-masked]>;
<[email-masked]>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

> Hi Shahram,
> yes, we need to settle on terminology related to protection.
> It was discussed and presented at the last IETF meeting how bi-directional
> BFD session easily can operate in, effectively, unidirectional mode. I
> think
> that operating BFD session in this mode is applicable to unidirectional
> and
> associated bi-directional p2p LSPs.
>
> Regards,
> Greg
>
> On Fri, Jun 11, 2010 at 11:54 AM, Shahram Davari
> <[email-masked]>wrote:
>
>>  Hi Greg,
>>
>>
>>
>> I assume by independent protection mode you mean unidirectional
>> protection.
>> If unidirectional protection is required, then it is simpler to not use
>>  bidirectional BFD session.
>>
>>
>>
>> Regards,
>>
>> Shahram
>>
>>
>>
>> *From:* Greg Mirsky [mailto:[email-masked]]
>> *Sent:* Friday, June 11, 2010 11:18 AM
>> *To:* Shahram Davari
>> *Cc:* Mach Chen; Mukund Mani; [email-masked]
>>
>> *Subject:* Re: [mpls-tp] Demultiplexing to BFD sessions
>>
>>
>>
>> Dear Shahram,
>> assume one BFD session is applied to an associated bi-directional LSP.
>> Then
>> failure in one direction will bring the session in Down state which is
>> not
>> desired behavior for independent protection mode. Thus, I think, need for
>> two BFD, in essence unidirectional, sessions.
>>
>> Regards,
>> Greg
>>
>> On Fri, Jun 11, 2010 at 11:03 AM, Shahram Davari <[email-masked]>
>> wrote:
>>
>> Hi,
>>
>> Why would one need to run more than one BFD session over an LSP?
>>
>> Thanks,
>> Shahram
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> Of Mach Chen
>> Sent: Friday, June 11, 2010 3:05 AM
>> To: Mukund Mani; [email-masked]
>> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>>
>> Hi Mukund,
>>
>> I also have the same question about this.
>>
>> As to the BFD discriminator, IMHO, we should keep using it as it be,
>> because
>> it may not be enough to demultiplex the BFD session only based on the
>> label,
>> this is especially true when there are more than two BFD sessions over
>> the
>> LSP.
>>
>> BTW, it seems that explicit null label distribution is not excluded (and
>> IMHO it should be excluded as PHP) in MPLS-TP (do I miss something?) ,
>> and
>> it is one of the issues that LSP-Ping for BFD session bootstrap is trying
>> to
>> reslove.
>>
>> Best regards,
>> Mach
>>
>> --------------------------------------------------
>> From: "Mukund Mani" <[email-masked]>
>> Sent: Friday, June 11, 2010 2:24 PM
>> To: <[email-masked]>
>> Subject: [mpls-tp] Demultiplexing to BFD sessions
>>
>> > Hi TP-Group
>> > **
>> > *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *states in Section 3
>> >
>> > "When using BFD over MPLS-TP LSPs, the BFD discriminator MUST either be
>> > signaled via LSP-Ping or be statically configured."
>> >
>> > *draft-ietf-mpls-tp-bfd-cc-cv-00 *states in Section 3.5.6
>> >
>> > "MPLS labels at peer MEPs are used to provide context for the received
>> BFD
>> > packets."
>> >
>> > As I understand from the statement in the CC/CV draft, since
>> discriminator
>> > values are not required for demultiplexing to the BFD session anymore,
>> > we
>> > will not need LSP Ping to bootstrap BFD session for TP LSP.
>> >
>> > But *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *specifies that LSP
>> > Ping
>> > can also be used to signal BFD discriminator.
>> >
>> > So is LSP Ping still really needed in the context of BFD over MPLS-TP?
>> >
>> > Also as a part of MPLS-TP OAM could somebody explain why such a
>> > deviation
>> > is
>> > taken from the BFD-BASE mode of demultiplexing which even BFD-MPLS uses
>> > (discriminator values instead of MPLS labels), but MPLS-TP goes in for
>> > demultiplexing using labels....
>> >
>> > Could somebody please clarify this..?
>> >
>> >
>> > With Regards
>> > Mukund
>> > <http://tools.ietf.org/html/draft-ietf-mpls-tp-bfd-cc-cv-00>
>> >
>>

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 13 Jun 2010 18:33:54 -0700

Dear Lavanya,
I agree with your and Mach rationale on Explicit Null label in regard to
transport packet network. But we need to remember that the MPLS-TP defines
packet switching network. The profile of packet transport will be based on
subset of features defined in MPLS-TP and it might be the case that PHP will
be disabled for packet transport networks based on MPLS-TP.

Regards,
Greg

On Sun, Jun 13, 2010 at 12:00 PM, Lavanya Srivatsa <
[email-masked]> wrote:

> (1) IMHO too, explicit null label distribution and PHP needs to be sorted
> out. If an OAM packet is received without the label, demultiplexing would
> become a problem. Even if the OAM packet contains discriminator values, if
> the packet does not carry the label, determining the LSP and therefore the
> destination MEP would be difficult in order to do CV (since only the source
> MEP TLV will be carried in the packet). Therefore I think the OAM context
> will be lost in case of PHP.
>
> BTW, can someone please clarify as to why the data plane draft introduces
> the "disabled by default" for PHP? I remember this point was raised by
> Curtis Villamizar earlier (Wed, 14 Apr 2010 ) but apart from someone
> suggesting that this gave the operator a choice, I dont seem to remember a
> concrete reason for this. IMHO, it should be "disabled at all times" for
> MPLS-TP networks.
>
> (2) Is there any draft which defines the "unidirectional " and
> "bidirectional" BFD sessions? I share Mach's confusion on this. Since the
> BFD state machine changes state based on what it receives from the peer node
> during session establishment, I think that a return path is necessary for
> the BFD session to be set up.
> Also, I am not sure why in order to perform unidirectional protection, a
> bidirectional BFD session need not/can not be used. I think even if we need
> to do unidirectional protection, all we need are the for 2 directions to
> operate independently, so that a fault in one direction of the path causes
> only that direction of the path to be moved on the protection/recovery path.
> So IMHO the number of sessions or unidirectional/bidirectional BFD sessions
> should be independent of the protection mechanism.
>
> - Lavanya
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 23:35:11 +0100

Lavanya,  I think you are missing the key role of the CV message wrt to
what is written below.....please see in-line for an explanation:
 
Lavanya Srivatsa wrote 13 June 2010 20:01
 
> (1) IMHO too, explicit null label distribution and PHP needs 
> to be sorted out.

NH=> Quite....these (vendor) optimisations are not great ideas IMO.

> If an OAM packet is received without the 
> label, demultiplexing would become a problem.

NH=> A key problem already exists irrespective of this.  We can take no
short-cuts on labelling whatsoever in cl-ps mode layer networks like IP
or Ethernet......the child traffic unit here must contain all the
absolute (ie for this layer network) labelling information it needs on
its journey from some SA location to some DA location....which means
each/every traffic unit must contain:
-	an absolute SA label, ie so the destination knows where it came
from
-	an absolute DA, ie the target sink location for
forwarding....and of course, no label-swapping is allowed in the cl-ps
mode
-	a client PID, ie to identify what specific client instance is
being carried in this server layer traffic unit message instance of SA
to DA server layer communication

In a co-ps mode layer network we can take lots of short-cuts on (child)
traffic unit labelling providing the (parent) connection entity respects
the single source requirement of a connection......which is a
pre-requisite anyway for any sort of useful resource management, ergo
why MPLS-TP mandates such single source constructs only....so this means
in each (child) traffic unit we can:
-	omit the SA label altogether 
-	only require a forwarding label to be link unique (amongst all
potential clients of a *given* link) when proxying for a DA of the
connection sink
-	omit the PID label altogether if the connection only carries a
single client over the connection lifetime

The problem we pay for taking these labelling short-cuts however is that
the network itself is now not self-protecting against misconnectivity,
ie the same forwarding label can be re-used on different links and so
traffic from one connection can be misdirected (and thus misforwarded)
into a different connection that just happens to be using the same link
local forwarding labels for the other connection.

This is why we MUST run a CV flow on ALL connections (irrespective of
their importance) in any co-ps mode network based on the non-ideal
label-swapping paradigm (though obviously the best designed co-ps mode
networks do not use label-swapping).

So even ignoring the amazingly bad idea per se of PHP, a label in itself
is not to be trusted when it comes to checking correct connectivity.
Some customers might be very keen that their 0perator network service
providers try and get this right, or at least know about misconnectivity
defects should they occur and take actions to protect their client
traffic integrity, eg squelch cases of detected misconnectivity.

So what we need in OAM CV (or BFD?) packets is not some arbitrary
source-node locally generated ID for a connection.  We need an
identifier which is the real connection SA and has global significance
in this layer network.....or over ALL layer networks for when we have
nested LSPs which might have both sublayering (ie, same layer network =
same routing instance = same addressing format) and layering (ie
different layer network = different routing instance = possibly same or
different addressing formats).

Of course, any properly designed transport network would not have such
sublayering/layering distinction problems at all.

> Even if the OAM 
> packet contains discriminator values, if the packet does not 
> carry the label, determining the LSP and therefore the 
> destination MEP would be difficult in order to do CV (since 
> only the source MEP TLV will be carried in the packet). 
> Therefore I think the OAM context will be lost in case of PHP.

NH=> Well yes, quite....but this misses the key point.  Once we have
succumbed to using a short-cut label-swapping way of co-ps mode
forwarding we can no longer trust the label even when we have the
decency not to discard it as it's only a proxy for a DA, and the
critical SA information that checks correct connectivity is missing
altogether from the traffic units anyway!  So operators who seriously
care about protecting their customers from misconnectivity need to
introduce CV (BFD?) OAM flows on ALL connections (irrespective of how
important they are) where the CV (BFD?) packets contain network
significant SA information and not some locally generated ID.

regards, Neil
> 
> BTW, can someone please clarify as to why the data plane 
> draft introduces the "disabled by default" for PHP? I 
> remember this point was raised by Curtis Villamizar earlier 
> (Wed, 14 Apr 2010 ) but apart from someone suggesting that 
> this gave the operator a choice, I dont seem to remember a 
> concrete reason for this. IMHO, it should be "disabled at all 
> times" for MPLS-TP networks.
> 
> (2) Is there any draft which defines the "unidirectional " 
> and "bidirectional" BFD sessions? I share Mach's confusion on 
> this. Since the BFD state machine changes state based on what 
> it receives from the peer node during session establishment, 
> I think that a return path is necessary for the BFD session 
> to be set up.
> Also, I am not sure why in order to perform unidirectional 
> protection, a bidirectional BFD session need not/can not be 
> used. I think even if we need to do unidirectional 
> protection, all we need are the for 2 directions to operate 
> independently, so that a fault in one direction of the path 
> causes only that direction of the path to be moved on the 
> protection/recovery path. So IMHO the number of sessions or 
> unidirectional/bidirectional BFD sessions should be 
> independent of the protection mechanism.
> 
> - Lavanya
> 
> 
> I have a little bit confusion about unidirectional and 
> bidirectional BFD session (and I failed to find where have 
> these definitions). Do you mean that unidirectional BFD 
> session only has forward path and no return path? My 
> understanding about a BFD session is that it should have both 
> forward and return paths, and if this is true and assume to 
> setup separate BFD session for each direction of an 
> associated bidirectional LSP, then the PEs of the LSP will 
> failed to demultiplex the BFD sessions.
> 
> Best regards,
> Mach
> 
> Cc: "Mach Chen" <[email-masked]>; "Mukund Mani" 
> <[email-masked]>; <[email-masked]>
> > It was discussed and presented at the last IETF meeting how 
> > bi-directional BFD session easily can operate in, effectively, 
> > unidirectional mode. I think that operating BFD session in 
> this mode 
> > is applicable to unidirectional and associated bi-directional p2p 
> > LSPs.
> >
> > Regards,
> > Greg
> >
> >> If unidirectional protection is required, then it is 
> simpler to not 
> >> use  bidirectional BFD session.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Shahram
> >>
> >>
> >>
> >> failure in one direction will bring the session in Down 
> state which 
> >> is not desired behavior for independent protection mode. Thus, I 
> >> think, need for two BFD, in essence unidirectional, sessions.
> >>
> >> Regards,
> >> Greg
> >>
> >> Behalf Of Mach Chen
> >> because it may not be enough to demultiplex the BFD session only 
> >> based on the label, this is especially true when there are 
> more than 
> >> two BFD sessions over the LSP.
> >>
> >> BTW, it seems that explicit null label distribution is not 
> excluded 
> >> (and IMHO it should be excluded as PHP) in MPLS-TP (do I miss 
> >> something?) , and it is one of the issues that LSP-Ping for BFD 
> >> session bootstrap is trying to reslove.
> >>
> >> Best regards,
> >> Mach
> >>
> >> > "When using BFD over MPLS-TP LSPs, the BFD discriminator MUST 
> >> > either be signaled via LSP-Ping or be statically configured."
> >> >
> >> > values are not required for demultiplexing to the BFD session 
> >> > anymore, we will not need LSP Ping to bootstrap BFD 
> session for TP 
> >> > LSP.
> >> >
> >> > But *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 
> *specifies that 
> >> > LSP Ping can also be used to signal BFD discriminator.
> >> >
> >> > deviation is taken from the BFD-BASE mode of 
> demultiplexing which 
> >> > even BFD-MPLS uses (discriminator values instead of MPLS 
> labels), 
> >> > but MPLS-TP goes in for demultiplexing using labels....
> >> >

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 14 Jun 2010 22:58:08 -0400

In message <[email-masked]>
[email-masked] writes:
[.. trimmed for brevity ..]
> significant SA information and not some locally generated ID.

Wow.  I agree with Neil on something.  It happens occasionally.  :-)

If I'm not mistaken, the LSP_TUNNEL SESSION object is needed to
identify the tunnel.  The LSP_ID should be ignored.  An example of
this in use would be a soft-preempt of an LSP which should be
minimally disruptive and not trigger an OAM DOWN event.  With this
method, a make-before-break should not interfere with CC/CV OAM as
long as the delay difference of the two LSP are not greater than the
CC/CV time out (this is why the timer should be configurable and *not*
fixed at specific values).

BTW- I haven't seen any discussion of the interaction of
make-before-break on MPLS-TP OAM.  AFAIK we are not disabling
make-before-break along with PHP and multipath (by default).

For the "no control plane" case the tunnel ID to expect in OAM can be
configured along with the label mapping.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 14 Jun 2010 23:28:07 -0400

In message <[email-masked]>
Lavanya Srivatsa writes:
> (1) IMHO too, explicit null label distribution and PHP needs to be
>     sorted out. If an OAM packet is received without the label,
>     demultiplexing would become a problem. Even if the OAM packet
>     contains discriminator values, if the packet does not carry the
>     label, determining the LSP and therefore the destination MEP would
>     be difficult in order to do CV (since only the source MEP TLV will
>     be carried in the packet). Therefore I think the OAM context will
>     be lost in case of PHP.
>  
> BTW, can someone please clarify as to why the data plane draft
> introduces the "disabled by default" for PHP? I remember this point
> was raised by Curtis Villamizar earlier (Wed, 14 Apr 2010 ) but apart
> from someone suggesting that this gave the operator a choice, I dont
> seem to remember a concrete reason for this. IMHO, it should be
> "disabled at all times" for MPLS-TP networks.

A sure path to failure is to ignore issues of interoperability with a
very large base of deployed hardware even if it is another vendor's
hardware.  That applies to product as well as protocol work.

We should not build OAM mechanisms that can not possibly interoperate
with the existing base of deployed hardware unless we want to
eliminate MPLS-TP applicability to deployed networks (and in doing so
hinder MPLS-TP deployment).

It may be that LM and DM cannot be provided with PHP because it is not
possible to count packets per LSP after the PHP LSR has removed the
top label, but it should still be possible to support CC/CV and most
other OAM functions.

>     "bidirectional" BFD sessions? I share Mach's confusion on
>     this. Since the BFD state machine changes state based on what it
>     receives from the peer node during session establishment, I think
>     that a return path is necessary for the BFD session to be set up.
>  
> Also, I am not sure why in order to perform unidirectional protection,
> a bidirectional BFD session need not/can not be used. I think even if
> we need to do unidirectional protection, all we need are the for 2
> directions to operate independently, so that a fault in one direction
> of the path causes only that direction of the path to be moved on the
> unidirectional/bidirectional BFD sessions should be independent of the
> protection mechanism.
>  
> - Lavanya
>  
>  
> I have a little bit confusion about unidirectional and bidirectional
> BFD session (and I failed to find where have these definitions). Do
> you mean that unidirectional BFD session only has forward path and no
> return path? My understanding about a BFD session is that it should
> have both forward and return paths, and if this is true and assume to
> setup separate BFD session for each direction of an associated
> bidirectional LSP, then the PEs of the LSP will failed to demultiplex
> the BFD sessions.
>  
> Best regards,
> Mach
>