Return-Path: 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 ; 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 ; 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 ; 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 To: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD Thread-Index: Ac1MpEwc7lLKqFncQ4ebgze3TT5Trg9lXFYAABDxxiA= Date: Tue, 4 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 09:24:32 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Carlos. Yes, IMHO the procedure of RFC 5885 that you quoted below can be adopted al= so for MPLS-TP. Assuming that in practice there is no PHP in MPLS-TP, the MPLS label provid= es 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] and Section 6 of [RFC5882]). 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 L= SP ping with TLV type 15 in the echo request/reply to exchange discriminato= r 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 replace= d with the correct value when the 1stcontrol packet is received from the pe= er. This behavior complies with another statement of the RFC "The transmitted Y= our Discriminator value MUST reflect back the received value of the My Disc= riminator field or be set to zero if that value is not known". Thanks, Muly _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Carlos.=

 <= /p>

Yes, IMHO the procedure o= f 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 fir= st BFD control packet and there is no need for LSP Ping bootstrapping.

 <= /p>

Muly

 <= /p>

From: Carlos P= ignataro (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 BF= D initialization procedures, which are also used in RFC 5885 [1]<= /o:p>

 

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

 

Thanks,

 

-- Carlos.

 

 

   o  Th=
e BFD Control packets are sent on the VCCV control channel.  The<=
/o:p>
      use of the VCCV control channel pr=
ovides the context required to
      bind and bootstrap the BFD session=
, since discriminator values are
      not exchanged; the pseudowire demu=
ltiplexer field (e.g., MPLS PW
      Label or L2TPv3 Session ID) provid=
es the context to demultiplex
      the first BFD Control packet, and =
thus single-hop BFD
      initialization procedures are foll=
owed (see Section&=
nbsp;3 of [RFC5881]
      and Section 6 of [RFC5882]).
 
   o  A single BFD session exists per pseudowire.&=
nbsp; 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:<= /o:p>



Hi,

 

We plan to implement the CC-CV-RDI func= tionality 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 re= quest/reply to exchange discriminator values?

 

RFC6428 is quite vague on this issue. I= t 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 d= iscriminator can be zero and replaced with the correct value when the 1stcontrol packet is received from the peer.

This behavior complies with another sta= tement 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
https://www.ietf.org= /mailman/listinfo/mpls

 

--_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_--