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

Greg Mirsky <gregimirsky@gmail.com> Thu, 01 November 2018 21:14 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCC012D4E9; Thu, 1 Nov 2018 14:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieGScNQk2YMN; Thu, 1 Nov 2018 14:14:05 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6940A127B92; Thu, 1 Nov 2018 14:14:04 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id z80-v6so13299276ljb.8; Thu, 01 Nov 2018 14:14:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1kuSILXEvWpJnQeu8h4YYLmI13mCkPdSDdI6NXAsU4k=; b=MpqHbMtblGzJ0dcALuE12JjChirpvdSMEsQCCxl92ecJwR0f7bjkYMWIg0Ne1Q2RuG FOm1bnakH8XbyO5moz1y62LBk0ra9lqKREMhAKapf8UuZCqMZQPcFBiHnrhki2GjHRzt zEVl6lf6L5yJKwGKWqJVe9TseguvMGE2MzKsLF559MWjC36Ln4EUQByJILhjlLkzrQLv ODdMEwxbfxK0SYL2yovPvQFLfXsxaxn4BFKSmtNu2O/rodvC7tZg0IK5zM83i7qfWvg1 0jN4tvyPg5OcC8uZQiAVjFm+AXgewH83OTp5WaFMImX2zK2Ht2phCUIBqrCHgahVgVes tz7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1kuSILXEvWpJnQeu8h4YYLmI13mCkPdSDdI6NXAsU4k=; b=Z0TEAezs2vYPeBK2BR5O7Rjo+0tl0M8XPNLt7aweBZ6fYbEnCN+3+driKKeEwkOD9/ ZP/RSLbA1mgVeIQlmT6NTdnKHz62CbSh2QF3Al+mNPQCG2MsZJUGUG/wwTXzyTHBI4n5 mBAmxpFBa8nhcc/XcXwjPzXN0uCb3zaqAApxsJy0qO/5xbpfpT/k/UTQxI/ZWkUxg6v5 egLJQGWWjFhDNKanRDyf5Oh7gBasd29Vf9y1g1UIf/w+JH3L07z/PwoqDh5CqNoG7Edx HGoj6PfPNnyUMC8i3r51cLMaAf/0VKkXaNBXEY0udaDY61/W9MGHbfF+U2k83RW2v7HH r6Rw==
X-Gm-Message-State: AGRZ1gJXzVOk474um6tbOHdV9tqSHBk5DoP0TpnktDvx+Cdxtv1ijid2 aAOrhBPrFwZQlgrp5gaft4sodjQCK47925Xq6/0=
X-Google-Smtp-Source: AJdET5dGxhWjKtVv2Tfn8RVgrPoL6OKo+/o97dQej0gOZJPpEG/0HZGuDG9uOkPCch3Hwad9bCYxbbop/o1WY6vGnOs=
X-Received: by 2002:a2e:800b:: with SMTP id j11-v6mr4346158ljg.114.1541106842472; Thu, 01 Nov 2018 14:14:02 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmVDvb6t3rh3sZUHrsApfJRb9A8GCLxPCe9b=tcvZz6J3w@mail.gmail.com> <15CB10A6-6AF4-460F-A71D-56F28D9D7784@cisco.com>
In-Reply-To: <15CB10A6-6AF4-460F-A71D-56F28D9D7784@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 1 Nov 2018 14:13:51 -0700
Message-ID: <CA+RyBmVbWkDK3o2ZREv2jat++O3hNWBA4_Yn-ynyDdjpG+GjXw@mail.gmail.com>
Subject: Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: mpls-chairs@ietf.org, mpls@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e81c810579a0e596"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/WrHsy0H3EqQ9jUAy_y-iIdT8PTg>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2018 21:14:08 -0000

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

Regards,
Greg

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

> Hi,
>
> Cc BFD WG
>
> 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.

>
> I’m also increasingly concerned by confusing scope and definition of
> specifications.
>
> For example:
>
> https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-04#section-3.2
>
> 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.

> Second, the specification in RFC 6428 applies to MPLS Transport Profile
> only. NOT for MPLS, and explicitly NOT for P2MP!
>
> https://tools.ietf.org/html/rfc6428#section-1
>
>    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.

>
> https://tools.ietf.org/html/rfc6428#section-4
>       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.

>       RFC 5085 - UDP/IP in G-ACh
>        MPLS-TP - CC/CV in GAL/G-ACh or G-ACh
>
>
>
> Thanks,
>
> — Carlos Pignataro
>
> On Oct 13, 2018, at 4:24 PM, Greg Mirsky <gregimirsky@gmail.com> 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.
>
> Regards,
> Greg
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>