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

Greg Mirsky <gregimirsky@gmail.com> Sun, 09 December 2018 02:23 UTC

Return-Path: <gregimirsky@gmail.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 C0C6B130DC1; Sat, 8 Dec 2018 18:23:52 -0800 (PST)
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 xK9J9Ymdl2T6; Sat, 8 Dec 2018 18:23:49 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 DF73612F1AC; Sat, 8 Dec 2018 18:23:48 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id c19-v6so6671385lja.5; Sat, 08 Dec 2018 18:23:48 -0800 (PST)
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=SrIPt198yLQDo0dnkGVywIBhHtqSotHGZ709ifhpyAo=; b=bL0rc3VDx1SOmzvaIlhEX8TqjZUg+HWUkU53VpGJyqS6vbxANxpkGYFM1c5CqaFeS1 CmkgJQH2T9eIFUDbf5OB1QroSmH5hVMAwi9m5xmcltjv0zwY6GTcSu/WevYnmOOvp6kZ 2anOslD2Bh0fvciv/hzlwj2j/N8bt4B0O4olvxeg4XNGEpWIUl0nyr9p2IXZrsce9RkI 7U1pAJkXXt9mU2Ar69j58FSm7I7EKoujS1cVQeGTNBbSs/TSm4L7rcCgETbbyKFWA8WF 9DsBDHobI1C5OJKkL+6HHsIRyQopMbG0iWGXFDPA+7d5w84OzoUVeqKI59y/kpNC6Ktm n1Rw==
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=SrIPt198yLQDo0dnkGVywIBhHtqSotHGZ709ifhpyAo=; b=j10nNiNradoxaZR4CLGW1DwHAla+3ZeLnXwWiFoxS7Kod5nJ1nV2xErB74VjlVqZ07 Z64wsGh03PrlwfQGfXoonIAXtY5N+tB0UhsbbPwcHUx93zbqTZhBUrQpA/ydFsJgpMly Xrexwiq8wc9s+BJlwdWSzuSydvh7iXwEH9+c/yNArInLOuigCntpgF5UAc85XZp8OAdy HNo2PBlaKD3oOihOvAw7MvPhLSXQEj1sVrGvB7o7yWqLALNpWKC87NvxQMnmiCQ89dpS JiH7biwPYS6Ce1ykVxTrZYfIM5Xqxc5wbSF0n4kD4uyWF5HPhAngb9m2DOoNiaOCejpT spXg==
X-Gm-Message-State: AA+aEWakW46NByW7ehSGAVRaReDov6vq6XUarisPVSx4EyEjhGVomKbM CFPFlSRPA7fC83wPH9TlGIoU2kd0erylwJDTk1k=
X-Google-Smtp-Source: AFSGD/UyiuolSk1FFNZqO6CoDWegNMrPa85o4FmS+ZawcDZrJz74yy2gEl3brBATvZZaMgTNUUX+p0o41hl8p4yBoZs=
X-Received: by 2002:a2e:92ca:: with SMTP id k10-v6mr4258481ljh.63.1544322226966; Sat, 08 Dec 2018 18:23:46 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmVDvb6t3rh3sZUHrsApfJRb9A8GCLxPCe9b=tcvZz6J3w@mail.gmail.com> <15CB10A6-6AF4-460F-A71D-56F28D9D7784@cisco.com> <CA+RyBmVbWkDK3o2ZREv2jat++O3hNWBA4_Yn-ynyDdjpG+GjXw@mail.gmail.com> <5BFD9FF7-DBF8-48E6-BF45-1D29AFB90034@cisco.com> <CA+RyBmVbRw3BsE8OdSmHcfasBi0te9BXvVC+8Cq9Zj-Asqc08Q@mail.gmail.com> <81371D06-2A1A-480F-B65D-FAF04E408A04@cisco.com> <CA+RyBmU2a-rcJ-BeHfYJ4PYqtxKx6s0J4+kpJxL3bUVCqXDz=w@mail.gmail.com> <88AC4C8C-C945-4B46-BA8D-42EDAA2EBEC8@cisco.com>
In-Reply-To: <88AC4C8C-C945-4B46-BA8D-42EDAA2EBEC8@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 8 Dec 2018 18:23:35 -0800
Message-ID: <CA+RyBmX_Pun_hgcfumtCKFGrOwv30G=FjbVtfbGqASD=4vRzTA@mail.gmail.com>
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="000000000000c1d525057c8d8921"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Brd5fmzhEmcTTYbKFzNgt2iyF6U>
Subject: Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 09 Dec 2018 02:23:53 -0000

Hi Carlos,
to answer your question the motivation of this work is to define the
applicability of draft-ietf-bfd-multipoint and
draft-ietf-bfd-multipoint-active-tail, including bootstrapping a BFD
session, to p2mp MPLS LSPs.

Regards,
Greg

On Sat, Nov 24, 2018 at 10:52 AM Carlos Pignataro (cpignata) <
cpignata@cisco.com>; wrote:

> Hi Greg,
>
> On Nov 21, 2018, at 7:00 AM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
>
> Hi Carlos,
> apologies for the prolonged silence. Thank you for your consideration of
> the proposed new text and the acknowledgment that we're converging.
>
>
> I do not recall (nor can I find below) any text from me with any
> acknowledgement of convergence. That is a misrepresentation.
>
> I do see you (not I) wrote below again (“Glad that we're converging.”) I
> do not see the basis for that.
>
> I did tell Loa I saw progress (not convergence) but also that my main
> question remained, in my humble opinion, unsatisfactorily answered.
>
>
> Please find the new comments in-line tagged GIM3>>.
>
> Regards,
> Greg
>
> On Wed, Nov 7, 2018 at 8:52 PM Carlos Pignataro (cpignata) <
> cpignata@cisco.com>; wrote:
>
>> [Greg, Loa, responding to both on this single email reply]
>>
>> Hi, Loa,
>>
>> On Nov 6, 2018, at 1:49 PM, Loa Andersson <loa@pi.nu>; wrote:
>>
>> Carlos,
>>
>> Since the a wg adoption poll I read your comments as that we are doing
>> progress, and that we can address the rest during the wg process,
>> correct?
>>
>>
>> I agree we are making progress, thank you. Most questions can be
>> addressed later, but only the very first question goes to the heart of an
>> adoption poll. If we can close on that, the rest can be addressed later
>> (note the same question is related also to the last question.)
>>
>> /Loa
>>
>>
>> Hi, Greg,
>>
>> Thank you very much for your responses — please see inline.
>>
>> On Nov 6, 2018, at 7:18 PM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
>>
>> Hi Carlos,
>> thank you for your consideration of my responses. Glad that we're
>> converging. Please find additional notes in-line tagged GIM2>>.
>>
>> Regards,
>> Greg
>>
>> On Tue, Nov 6, 2018 at 12:11 AM Carlos Pignataro (cpignata) <
>> cpignata@cisco.com>; wrote:
>>
>>> Hi Greg,
>>>
>>> Many thanks for your response and suggestions! Please see inline.
>>>
>>> On Nov 2, 2018, at 6:13 AM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>> GIM2>> Thank you for agreeing to this, and I've added the text in the
>> working verion. Will work on improving the text in the meantime.
>>
>>
>> CMP: Sorry if I was not clear. Like I said, this is a good start and
>> probably necessary (but not sufficient) text.
>>
>> CMP: Which environments specifically? At this point, the scope and target
>> of the work is not clear to me. That was my question. Is this for MPLS-TP
>> P2MP? If so, the underlying seems to have stalled:
>> https://datatracker.ietf.org/doc/rfc7167/referencedby/
>> CMP: I think these two questions should be answered: 1. What specific
>> environments? 2. How current solutions do not solve it (i.e., what is and
>> can we quantify the overburden)?
>>
> GIM3>> Andy Malis has pointed to the requirements for proactive OAM,
> particularly monitoring path continuity, listed in Section 4.1 RFC 4687.
>
>
> Just to understand — the basis of this work is Requirements from RFC 4687
> from the year 2006?
>
> These are not specific to MPLS-TP but to OAM over p2mp MPLS LSP. The
> following text has been added to the Security Considerations section in the
> recenly uploaded -04 version of the draft:
>
>
> Adding scope and rationale for some work in the Security Considerations
> does not seem like the right sequentiality to set the stage.
>
>    Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in
>    section 4.1 [RFC4687] to avoid congestion in the control plane or the
>    data plane caused by the rate of generating BFD control packets.  An
>    operator SHOULD consider the amount of extra traffic generated by
>    p2mp BFD when selecting the interval at which the MultipointHead will
>    transmit BFD control packets.  Also, the operator MAY consider the
>    size of the packet the MultipointHead transmits periodically as using
>    IP/UDP encapsulation adds up to 28 octets, which is more than 50% of
>    BFD control packet length, comparing to G-ACh encapsulation.
>
>>
>>
>>>
>>>> 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.
>>>
>>>
>>> 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?
>>>
>> GIM2>> I think that the following quote from RFC 5586 set the
>> relationship between Channel Type field in PW ACH and G-ACh:
>>     Channel Types for the Associated Channel Header are allocated from
>>     the IANA "PW Associated Channel Type" registry [RFC4446].
>> I understand that that there's one and only one registry and channel
>> values are equally applicable to PW ACH and G-ACh. And full name of the
>> registry now is MPLS Generalized Associated Channel (G-ACh) Types
>> (including Pseudowire Associated Channel Types).
>>
>>
>> CMP: That is correct. I was curious as to whether additional control
>> plane is needed for this support.
>>
>>
>>> 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.
>>>
>>>
>>> CMP: This is the same comment as above.
>>>
>>>
>>>> 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.
>>>
>>>
>>>
>>> CMP: Apologies I did not understand this response.
>>>
>> GIM2>> Apologies for sending partial explanation. P2MP BFD cannot use
>> Your Discriminator field to demultiplex the recieved BFD control packet.
>> BFD for Multipoint Networks defines the special procedure that requires the
>> use of Source ID. When the encapsulation of BFD control packet does not
>> include IP/UDP header, the Source ID can be provided as Source MEP-ID TLV
>> in MPLS-TP BFD CV. This draft proposes the new IP Address TLV for that.
>> Thus I have to correct myself and re-state the earlier text in the draft
>> that the value in the Channel Type filed of G-ACh must be MPLS-TP CV
>> (0x0023).
>>
>>
>> CMP: I understood you said above that the reference to RFC6428 was
>> incorrect.
>>
>> CMP: Now, just to understand the approach:
>>
>> CMP: Are you suggesting that the IP header is not used with BFD and
>> instead a new TLV (of which information structure?) carries the IP address
>> that you removed before? Seems like a musical-chairs arrangement of the
>> data. I may very likely be missing something. Apologies in advance if that
>> is the case.
>>
>> CMP: Also, is the applicability MPLS-TP? What is the normative reference
>> for MPLS-TP P2MP?
>>
> GIM3>> I should have explained why I think that MPLS-TP CV message
> (0x0023) type is more suitable than BFD Control, PW-ACH encapsulation
> (without IP/UDP Headers) (0x0007). The latter includes only the BFD control
> packet while the format of the former includes Source MEP-ID TLV that
> immediately follows the BFD control packet. And with the new proposed IP
> Address TLV the 0x0023 G-ACh channel works better for p2mp BFD over p2mp
> MPLS LSP. Alternative, of course, would be to define the new G-ACh type for
> p2mp BFD over p2mp MPLS LSP.
>
>>
>>
> Thanks — I appreciate that a lot of packet formats could be drawn. My
> question is really regarding motivation for the work (the vague “ In some
> environments”)
>
> Thanks,
>
> — Carlos.
>
> Thanks,
>>
>> Carlos.
>>
>>
>>> CMP: Thanks again for considering the comment to improve the document.
>>>
>>> Thanks,
>>>
>>> Carlos.
>>>
>>>
>>>       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
>>>>
>>>>
>>>
>>
>