Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd

"Carlos Pignataro (cpignata)" <> Mon, 05 November 2018 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3618E1277CC; Mon, 5 Nov 2018 09:11:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JIIdnT8cXXda; Mon, 5 Nov 2018 09:11:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7A7A127332; Mon, 5 Nov 2018 09:11:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=23416; q=dns/txt; s=iport; t=1541437873; x=1542647473; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MTBgH0UunzZeNO808suKC2PTlx5SKTAff2S+eMYEkYI=; b=V7L9kzxNnpqv0m6flGFv0XbR5gqWQBIZ5+Dhmx31Oyd7DxOMQiUtOHK/ IGtAf4QoHlWVaXkBXhGKP/WXlak1+STB7XiwVr9u4XH7oYv14b9LdNcK0 RyeoSkVagYUxYJ6sBD5Gesy2nqbSg/T55dDXkXhtDqsvjzuTHpNqr5pT+ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,468,1534809600"; d="scan'208,217";a="480068041"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 17:11:12 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id wA5HB6HB030623 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Nov 2018 17:11:12 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Nov 2018 12:11:05 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Mon, 5 Nov 2018 12:11:05 -0500
From: "Carlos Pignataro (cpignata)" <>
To: Greg Mirsky <>
CC: "" <>, mpls <>, rtg-bfd WG <>
Subject: Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd
Thread-Topic: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd
Thread-Index: AQHUcjCnBAZrmoA7/EOd5Vk0epnVbaVBxIEA
Date: Mon, 05 Nov 2018 17:11:05 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.101.1)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5BFD9FF7DBF848E6BF451D29AFB90034ciscocom_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Nov 2018 17:11:16 -0000

Hi Greg,

Many thanks for your response and suggestions! Please see inline.

On Nov 2, 2018, at 6:13 AM, Greg Mirsky <<>> wrote:

Hi Carlos,
thank you for your comments. Please find my notes, answers in-line tagged GIM>>.


On Thu, Oct 25, 2018 at 8:47 PM Carlos Pignataro (cpignata) <<>> wrote:


It would be useful to understand the use case motivation or applicability of this draft, other than it can be done.
GIM>>  The motivation can be seen in the following (from another draft that discusses OAM over G-ACh:
  In some
   environments, the overhead of extra IP/UDP encapsulations may be
   considered as overburden and make using more compact G-ACh
   encapsulation attractive.
Will add text in the draft.

CMP: Thank you very much. This is a good start, although it would be useful to add precision into which environments specifically, and the burden comparison between IP/UDP and G-ACh.

I’m also increasingly concerned by confusing scope and definition of specifications.

For example:

3.2.  Non-IP Encapsulation of Multipoint BFD

   Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP MUST use
   Generic Associated Channel (G-ACh) Label (GAL) [RFC5586] at the
   bottom of the label stack followed by Associated Channel Header
   (ACH).  Channel Type field in ACH MUST be set to BFD CV [RFC6428].

First, there’s no definition for non-IP BFD in RFC 5586 — only in RFC 5885.
GIM>> RFC 5586 defined the use of GAL. I think that this reference is appropriate. I agree that the second reference should be to RFC 5885, not RFC 6428. Will make the change.

CMP: Thank you. However, RFC 5885 is in the context of PW VCCV — is there a missing definition in the specs for BFD over G-ACh generically?

Second, the specification in RFC 6428 applies to MPLS Transport Profile only. NOT for MPLS, and explicitly NOT for P2MP!

   This document specifies the BFD extension and behavior to satisfy the
   CC, proactive CV monitoring, and the RDI functional requirements for
   both co-routed and associated bidirectional LSPs.  Supported
   encapsulations include Generic Associated Channel Label (GAL) /
   Generic Associated Channel (G-ACh), Virtual Circuit Connectivity
   Verification (VCCV), and UDP/IP.  Procedures for unidirectional
   point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for
   further study.

So, no, this does not work.

RFC 6428 does not have scope for P2MP.
And RFC 5586 does not specify anything for BFD. Instead, what needs to be cited (appropriately and expanded) is RFC 5885
GIM>> RFC 5586 specifies the use of GAL and G-ACh and the reference is used in this context.

CMP: This is the same comment as above.
      RFC 5884 - BFD CC in UDP/IP/LSP
      RFC 5885 - BFD CC in G-ACh
GIM>> I'd point that it is for p2p BFD CC, and p2mp BFD uses different from p2p BFD method to demultiplex BFD control packets.

CMP: Apologies I did not understand this response.

CMP: Thanks again for considering the comment to improve the document.



      RFC 5085 - UDP/IP in G-ACh
       MPLS-TP - CC/CV in GAL/G-ACh or G-ACh


— Carlos Pignataro

On Oct 13, 2018, at 4:24 PM, Greg Mirsky <<>> wrote:

Dear WG Chairs, et al.,
as the author of the BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP (draft-mirsky-mpls-p2mp-bfd) I would like to ask you to consider WG adoption call of the draft. The document addresses non-IP encapsulation of p2mp BFD over MPLS LSP that may be useful if the overhead of IP, particularly IPv6, encapsulation is the concern. The base specification of BFD for Multipoint Networks is at this time in IESG LC.

mpls mailing list<>