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) < cpign...@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 <gregimir...@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 > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > >
