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