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

[Greg Mirsky <[e-mail]>]

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) <
[e-mail]> wrote:

> Hi Greg,
>
> On Nov 21, 2018, at 7:00 AM, Greg Mirsky <[e-mail]> 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) <
> [e-mail]> wrote:
>
>> [Greg, Loa, responding to both on this single email reply]
>>
>> Hi, Loa,
>>
>> On Nov 6, 2018, at 1:49 PM, Loa Andersson <[e-mail]> 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 <[e-mail]> 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) <
>> [e-mail]> wrote:
>>
>>> Hi Greg,
>>>
>>> Many thanks for your response and suggestions! Please see inline.
>>>
>>> On Nov 2, 2018, at 6:13 AM, Greg Mirsky <[e-mail]> 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) <
>>> [e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>>
>>>
>>
>