Re: [mpls-tp] Demultiplexing to BFD sessions

[Mukund Mani <[e-mail]>]

Hi Apratim/Greg

IMHO the MEP id will be different.  Eg as far as the identification goes say
the forward direction is from node A to node B, MEP for the forward path can
be identified as A::Tnl X::LSP1 and the reverse path MEP can be identified
as B::Tnl Y::LSP2.

With Regards
Mukund

On Wed, Jun 30, 2010 at 12:07 PM, Apratim Mukherjee
<[e-mail]>wrote;wrote:

> Hi Greg
>
> That makes sense and is a good solution.
> However , probably MEP Id currently consists of global id + node id + src
> tunnel id + dest tunnel id + lsp id ..We will need to either make lspid
> different for Tx and Rx side ( does not seem to be the case as defined today
> ) or add + tx/rx identifier to the MEP Id to make it unique. And add
> requirement that for independent mode at least , BFD should work in CC-CV
> mode only.
>
> Regards,
> Apratim
> P.S. Changed back to plain text to meet mail size limit.
>
>
> ==========================================================================================================
> From: Greg Mirsky [mailto:[e-mail]]
> Sent: Wednesday, June 30, 2010 10:51 AM
>  To: Apratim Mukherjee
> Cc: David Allan I; Shahram Davari; Mukund Mani; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
> Dear Apratim,
> I think "independent" OAM uni-directional OAM session requires separate MEG
> and, consequently, MEP ID will be unique for each session, direction of the
> bi-directional LSP in your scenario. That is why I think that MEP ID TLV
> would not be the same as you've suggested.
> Your point that MEP ID is not required in CC OAM is absolutely correct. I
> think that another reason not to have CC but only CV/RDI.
>
> Regards,
> Greg
>
> ==========================================================================================================
> 2010/6/29 Apratim Mukherjee <[e-mail]>
> Hi Greg
>
> But in the particular case I am trying to point out, the MEP ID would also
> appear to be same for ‘independent’ BFD sessions. In which case we are back
> to square one. Unless my understanding of ‘independent’ BFD sessions is
> incorrect somewhere which is also possible. (Also note that as current draft
> stands, MEP ID would be there only for CC-CV type , not for CC type of BFD
> OAM packets.)
>
> In all other cases I do agree that either MEP ID ( globally unique so looks
> safer ) or label stack ( packets could leak to incorrect MEP though in this
> case ) can be used to determine the LSP for which the BFD OAM packet has
> been received.
>
> Regards,
> Apratim
>
> ===================================================================================================
> From: Greg Mirsky [mailto:[e-mail]]
> Sent: Wednesday, June 30, 2010 10:21 AM
> To: Apratim Mukherjee
> Cc: David Allan I; Shahram Davari; Mukund Mani; [e-mail];
> [e-mail]; [e-mail]
>
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
> Dear Apratim,
> please note that even if Your Discriminator == 0 the CC/CV/RDI OAM packet
> carries Unique MEP ID. Personally, I don't see benefit of using
> discriminator when there's Unique MEP ID. We can make check of Your
> Discriminator optional and not affecting state of OAM/BFD session.
>
> Regards,
> Greg
> On Tue, Jun 29, 2010 at 9:20 PM, Apratim Mukherjee <[e-mail]>
> wrote:
> Hi
>
> Leaving aside PHP , Implicit NULL and Explicit NULL which as per   Section
> 2.3 of RFC5654  Requirements of an MPLS Transport Profile
> “38  A transport path on a link MUST be uniquely identifiable by a single
> label on that link.”  appears to disallow BOTH PHP and Explicit NULL
> assignment by egress in MPLS-TP context . Hope this understanding is
> correct.
> Probably , the reference by John in his mail  from (
> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane) "PHP
> Penultimate Hop Popping (PHP) MUST be disabled by default." is misleading
> sinceit does not talk about Explicit NULL issue and does not seem to be
> aligned with the Requirements RFC which should take precedence. Maybe needs
> to be updated ?
>
> However , below arguments that always we can derive BFD session from label
> stack does not appear correct in one particular case (ruling out Explicit
> NULL and Implicit NULL assignment by egress for MPLS-TP)  :
>
> draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD: ( This is from a
> previous mail to which I did not get any replies )
> Situation : BFD is providing independent service over the Tx and Rx links
> of an active bidirectional MPLS-TP LSP  (say because this lsp is part of a
> 1+1 protection group supporting uni-directional protection switching )
>                Node A                       Node B
>                OutLabel = L11                 InLabel  = L11
>                InLabel  = L12                 OutLabel = L12
> This bidirectional LSP is configured to run two *independent* BFD sessions
> , one BFD session helping Node B to detect that its Rx connection via
> InLabel L11 is good , and the other helping Node A to detect that its Rx
> connection via InLabel L12 is good.
> Node A receives two sets of BFD control packets :
> 1) For the session in which it is 'active' ( rarely, during state changes
> only),i.e. these packets have MinRxInterval set to 0
> 2) The BFD packets Node A receives for the session in which it is
> 'passive', every 3.33/10ms will be identical if BFD packet for both sessions
> contain 0 in 'Your Discriminator' field .
>
> Hence , if the two sessions were to be independent , the Discriminators
> need to be present and right from the first packet (i.e. cannot be 0 in
> initial packet ) . Or separate mechanism must be identified. Deriving the
> BFD session from the label stack alone appears to be not possible in this
> case.  It is from same source to same destination using same label stack.
>
> Possible solutions if above problem is real and the analysis is correct :
> 1) Mandatory use of pre-exchange of Discriminators via LSP Ping or manual
> configuration before running BFD in ‘independent mode’.i.e no BFD packet
> contains 0 Your Discriminator when running in ‘independent mode’ (
> Discriminator becomes must)
> OR
> 2) If ‘Your Discriminator’ is 0 , use Label Stack + Min Rx Interval ( 0 /
> non-zero ) to derive packet is for which session.-> does not look good at
> all  but does completely remove Discriminator from being part of session
> demultiplexer .
> 3) Implement ‘independent’ BFD sessions in  some other manner.
>
> Please share your comments.
>
>
> Regards,
> Apratim
>
> =============================================================================================================
> From: Greg Mirsky [mailto:[e-mail]]
> Sent: Wednesday, June 30, 2010 6:57 AM
> To: David Allan I
> Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
> Dear David,
> received in Your Discriminator value is unique for the receiver and not
> necessarily for the sender of the BFD control packet. Transmitting in every
> CV/CC/RDI packet discriminator along with Unique MEP ID, in my view, is
> redundant.
>
> Regards,
> Greg
> 2010/6/29 David Allan I <[e-mail]>
> My understanding (and the text in 6.3 of RFC 5880 agrees with me) that the
> discriminator value is per platform unique, and not necessarily confined to
> a having uniqueness to a particular node pair.
>
> So local state can be indexed directly via the discriminator for any BFD
> packet received by a node.
>
> cheers
> D
>
> ________________________________________
> From: Greg Mirsky [mailto:[e-mail]]
> Sent: Tuesday, June 29, 2010 2:18 PM
> To: David Allan I
> Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; [e-mail];
> [e-mail]; [e-mail]
>
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
> Dear David,
> I tend to agree with Shahram that for MPLS-TP discriminator check even for
> bi-directional p2p path is optional. And for uni-directional, recalling BFD
> for multi-point network, demultiplexing mechanism was modified when compared
> with BFD base. Said that I realize that to be interoperable an
> implementation will have to support the discriminator check perhaps as
> default behavior. Well, unless we agree that the discriminator has no role
> in demultiplexing OAM/BFD sessions between same pair of nodes at all. Which
> will make discriminator field unnecessary as well as mechanisms of
> exchanging them (LSP Ping bootstrap of BFD session). That will, in my view,
> simplify the OAM solution based on BFD.
>
> another .02 in the bank
>
> Regards,
> Greg
> 2010/6/29 David Allan I <[e-mail]>
> But if the goal is to leverage a common implementation the discriminator
> needs to be present. There should be a further check that the label of
> arrival is correct for a given discriminator.
>
> Hence one primary state indexing mechanism, and further more authoritative
> tests of correctness chain from that..
>
> my 2 cents
> D
>
> ________________________________________
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Shahram Davari
> Sent: Tuesday, June 29, 2010 1:31 PM
> To: Mukund Mani; Apratim Mukherjee; [e-mail]
>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
> Hi,
>
> Discriminator should not be required for MPLS-TP since Explicit Null and
> PHP are not allowed in MPLS-TP.  For MPLS-TP the Label should be enough to
> provide the demultiplexing context.
>
> Regards,
> Shahram
>
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Mukund Mani
> Sent: Monday, June 28, 2010 10:39 AM
> To: Apratim Mukherjee; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
> Hi Xiao/Apratim
>
> I think discriminators are needed in some of the cases (eg explicit NULL)
> as mentioned below. This is what I was trying to state
> in my initial mails.
> Should it also seen on the lines that LSP Ping itself, if used, for
> bootstrap can help in performing a sort of a mis-connectivity check (In CV
> mode this is done via the MEP id included in the BFD control packet. In CC
> mode the MEP id is not included)
> Though I feel that CC and CV mode should be collapsed to one (CV) but thats
> another discussion (or probably already discussed)
>
> With Regards
> Mukund
> 2010/6/28 Apratim Mukherjee <[e-mail]>
> Hi Xiao/Mukund ,
>
> I think for normal bi-directional ‘fate-sharing’ BFD bidirectional session
> with no PHP and no explicit NULL assignment at the egress , the bootstrap
> mechanism is not really needed since the Label Stack does provide the
> context at the receiving end for identifying the local BFD session.
> ( same as how IP header gives the context for IPv4 BFD with Your
> Discriminator ‘0’ )
>
> RFC5885 works fine without knowing  peer Discriminator value from before
> since this is a PW connection , which means that egress assigns a label
> which is NOT Implicit NULL or Explicit NULL.
>
> However , this does not appear to work if egress has assigned Implicit NULL
> or Explicit NULL . ( Not clear if both are disallowed , appears to me at
> least first one is not supported in MPLS-TP but nowhere Explicit NULL is
> explicitly ruled out  ) . For MPLS-TP , the mechanisms being designed should
> work for normal LSPs as well ( not only for PWs that is ) .
>
> The other case where above does not appear to work is for ‘independent’ BFD
> sessions . ( I had sent a mail regarding that , but no replies yet ) in
> which two ‘non fate-sharing’ BFD sessions are required to protect each
> direction of a bi-directional connection separately. There also it does not
> look like we can derive local  BFD session correctly from a packet received
> with ‘Your Discriminator’ set to 0 .
>
> Regards,
> Apratim
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: Monday, June 28, 2010 7:57 AM
> To: Mukund Mani
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
>
> Hi Mukund,
>
> To my understanding, discriminator exchange is applicable in some scenario,
> but not necessary in other scenario, for BFD session bootstrap.
>
> In RFC5884 section 3.2, it's indicated that LSP Ping is used to exchange
> discriminator and bootstrap the BFD session; But in RFC5885 section 3.1,
> it's also indicated that the VCCV control channel provides the context
> required to bootstrap the BFD session and no discriminator exchange needed.
>
> In the MPLS-TP context, IMO it's similar to the scenario in RFC5885 and no
> discriminator exchange is needed to bootstrap BFD session.
>
> Best Regards,
> Xiao Min
> Mukund Mani <[e-mail]>
> 发件人:  [e-mail]
> 2010-06-11 14:24
> 收件人
> [e-mail]
> 抄送
>
> 主题
> [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
>  _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>
>