Re: [mpls-tp] Demultiplexing to BFD sessions

[<[e-mail]>]

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
 
> I am with Mach on both counts - 
> 
> (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
> 
> 
> Date: Sat, 12 Jun 2010 10:22:00 +0800
> From: Mach Chen <[e-mail]>
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
> To: Greg Mirsky <[e-mail]>om>, Shahram Davari
>         <[e-mail]>
> Cc: Mukund Mani <[e-mail]>om>, [e-mail]
> 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" <[e-mail]>
> Sent: Saturday, June 12, 2010 3:02 AM
> To: "Shahram Davari" <[e-mail]>
> Cc: "Mach Chen" <[e-mail]>om>; "Mukund Mani" 
> <[e-mail]>om>; <[e-mail]>
> 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
> > <[e-mail]>wrote;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:[e-mail]]
> >> *Sent:* Friday, June 11, 2010 11:18 AM
> >> *To:* Shahram Davari
> >> *Cc:* Mach Chen; Mukund Mani; [e-mail]
> >>
> >> *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 
> >> <[e-mail]>
> >> wrote:
> >>
> >> Hi,
> >>
> >> Why would one need to run more than one BFD session over an LSP?
> >>
> >> Thanks,
> >> Shahram
> >>
> >>
> >> -----Original Message-----
> >> From: [e-mail] 
> [mailto:[e-mail]] On 
> >> Behalf Of Mach Chen
> >> Sent: Friday, June 11, 2010 3:05 AM
> >> To: Mukund Mani; [e-mail]
> >> 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" <[e-mail]>
> >> Sent: Friday, June 11, 2010 2:24 PM
> >> To: <[e-mail]>
> >> 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>
> >> >
> >>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>