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

[Greg Mirsky <[e-mail]>]

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.

>
>
>> 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).

>
> 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: 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
>>
>>
>