Re: [mpls-tp] Demultiplexing to BFD sessions

"Shahram Davari" <davari@broadcom.com> Tue, 29 June 2010 17:31 UTC

Return-Path: <davari@broadcom.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3D63A6930; Tue, 29 Jun 2010 10:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEuHZCKCIbup; Tue, 29 Jun 2010 10:31:07 -0700 (PDT)
Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 96B903A6862; Tue, 29 Jun 2010 10:31:05 -0700 (PDT)
Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 29 Jun 2010 10:31:08 -0700
X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201
Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 29 Jun 2010 10:31:08 -0700
From: "Shahram Davari" <davari@broadcom.com>
To: "Mukund Mani" <mukund.mani@gmail.com>, "Apratim Mukherjee" <AMukherjee@ixiacom.com>, "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>
Date: Tue, 29 Jun 2010 10:31:04 -0700
Thread-Topic: [mpls-tp] Demultiplexing to BFD sessions
Thread-Index: AcsW6O7UQrM6ulfNSPWa6j9/JjO8JAAx4YKg
Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6940E808F75@SJEXCHCCR02.corp.ad.broadcom.com>
References: <AANLkTikZurkVBrPNBjL-v7zdZ9dTLUBDuBnNDPsCrnJf@mail.gmail.com> <OF7E03B6CE.B5C7073D-ON48257750.000D15FC-48257750.000D4123@zte.com.cn> <716209EC190CA740BA799AC4ACCBFB5D180C3C7126@IXCAEXCH07.ixiacom.com> <AANLkTikdY-qChtT8-po0L6eCjW6qWQ2LzqMhG1eysmvP@mail.gmail.com>
In-Reply-To: <AANLkTikdY-qChtT8-po0L6eCjW6qWQ2LzqMhG1eysmvP@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 6034F2563KC20247546-01-01
Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6940E808F75SJEXCHCCR02co_
Cc: "mpls-tp-bounces@ietf.org" <mpls-tp-bounces@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2010 17:31:24 -0000

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: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Mukund Mani
Sent: Monday, June 28, 2010 10:39 AM
To: Apratim Mukherjee; xiao.min2@zte.com.cn
Cc: mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
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 <AMukherjee@ixiacom.com<mailto:AMukherjee@ixiacom.com>>
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: mpls-tp-bounces@ietf.org<mailto:mpls-tp-bounces@ietf.org> [mailto:mpls-tp-bounces@ietf.org<mailto:mpls-tp-bounces@ietf.org>] On Behalf Of xiao.min2@zte.com.cn<mailto:xiao.min2@zte.com.cn>
Sent: Monday, June 28, 2010 7:57 AM
To: Mukund Mani
Cc: mpls-tp-bounces@ietf.org<mailto:mpls-tp-bounces@ietf.org>; mpls-tp@ietf.org<mailto:mpls-tp@ietf.org>
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 <mukund.mani@gmail.com<mailto:mukund.mani@gmail.com>>
发件人:  mpls-tp-bounces@ietf.org<mailto:mpls-tp-bounces@ietf.org>

2010-06-11 14:24

收件人

mpls-tp@ietf.org<mailto:mpls-tp@ietf.org>

抄送

主题

[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
mpls-tp@ietf.org<mailto:mpls-tp@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls-tp