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

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