Re: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD

Muly Ilan <muly_i@rad.com> Tue, 04 September 2012 09:24 UTC

Return-Path: <muly_i@rad.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB6221F8648 for <mpls@ietfa.amsl.com>; Tue, 4 Sep 2012 02:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwsqt1EGqV6e for <mpls@ietfa.amsl.com>; Tue, 4 Sep 2012 02:24:30 -0700 (PDT)
Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id DB18D21F853B for <mpls@ietf.org>; Tue, 4 Sep 2012 02:24:27 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay02 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 4 Sep 2012 11:35:58 +0300
Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 12:24:08 +0300
From: Muly Ilan <muly_i@rad.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD
Thread-Index: Ac1MpEwc7lLKqFncQ4ebgze3TT5Trg9lXFYAABDxxiA=
Date: Tue, 04 Sep 2012 09:24:08 +0000
Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC8704316FC6@EXRAD5.ad.rad.co.il>
References: <32CB7A1F0806AB4688CE3F22C29DAC87042C27ED@EXRAD5.ad.rad.co.il> <21D4E582-9050-47AF-A1D8-B17B58BDCCAE@cisco.com>
In-Reply-To: <21D4E582-9050-47AF-A1D8-B17B58BDCCAE@cisco.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.17.170.136]
Content-Type: multipart/alternative; boundary="_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_"
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A020203.5045C8B9.0145,ss=1,fgs=0
Cc: "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Sep 2012 09:24:32 -0000

Thanks Carlos.

Yes, IMHO the procedure of RFC 5885 that you quoted below can be adopted also for MPLS-TP.
Assuming that in practice there is no PHP in MPLS-TP, the MPLS label provides the context to the first BFD control packet and there is no need for LSP Ping bootstrapping.

Muly

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Tuesday, September 04, 2012 7:08 AM
To: Muly Ilan
Cc: mpls@ietf.org
Subject: Re: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD

What you describe seems to be the single-hop BFD initialization procedures, which are also used in RFC 5885 [1]

It is not totally clear to me how tightly tied the procedures from RFC 6428 are to the bootstrapping from RFC 5884 using LSP Ping, versus a single-hop initialization without discriminators exchanged. The document seems to be slightly vague there, though I do not know how it would affect.

Thanks,

-- Carlos.

[1] http://tools.ietf.org/html/rfc5885#section-3.1


   o  The BFD Control packets are sent on the VCCV control channel.  The

      use of the VCCV control channel provides the context required to

      bind and bootstrap the BFD session, since discriminator values are

      not exchanged; the pseudowire demultiplexer field (e.g., MPLS PW

      Label or L2TPv3 Session ID) provides the context to demultiplex

      the first BFD Control packet, and thus single-hop BFD

      initialization procedures are followed (see Section 3 of [RFC5881]<http://tools.ietf.org/html/rfc5881#section-3>

      and Section 6 of [RFC5882]<http://tools.ietf.org/html/rfc5882#section-6>)



   o  A single BFD session exists per pseudowire.  Both PW endpoints

      take the Active role sending initial BFD Control packets with a

      Your Discriminator field of zero, and BFD Control packets received

      with a Your Discriminator field of zero are associated to the BFD

      session bound to the PW.


On Jun 17, 2012, at 12:14 PM, Muly Ilan wrote:


Hi,

We plan to implement the CC-CV-RDI functionality per RFC6428.

Is it mandatory to support LSP ping as a bootstrap for the BFD i.e. using LSP ping with TLV type 15 in the echo request/reply to exchange discriminator values?

RFC6428 is quite vague on this issue. It only states "Overall operation is as specified in RFC 5880 [4] and augmented for MPLS in RFC 5884 [8].".

IMHO, the initial value of the remote discriminator can be zero and replaced with the correct value when the 1stcontrol packet is received from the peer.
This behavior complies with another statement of the RFC "The transmitted Your Discriminator value MUST reflect back the received value of the My Discriminator field or be set to zero if that value is not known".


Thanks,

Muly
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls