I think my suggested revision was a significant improvement so I've gone ahead with these minor changes and postes a -07 version.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Sat, Mar 27, 2021 at 3:54 PM Martin Duke <[email protected]> wrote: > > I straight up missed that definition. So use whichever text you prefer. > > Thanks for adding the references. > > On Sat, Mar 27, 2021, 12:47 Donald Eastlake <[email protected]> wrote: >> >> Hi Martin, >> >> On Fri, Mar 26, 2021 at 12:23 PM Martin Duke via Datatracker >> <[email protected]> wrote: >> > >> > Martin Duke has entered the following ballot position for >> > draft-ietf-bess-evpn-oam-req-frmwk-06: No Objection >> > >> > ... >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > Thanks to David Black for the tsvart review, and for the authors >> > addressing his comments. >> > >> > Sec 2.2 It would help to define "up" and "down" connections. >> >> The -06 version of the draft includes the following text which sort of >> defines "up" and "down" but I'm not sure it does so clearly or even >> completely accurately in this case :-( >> >> The EVPN PE MUST support MIP functions in the applicable service OAM >> protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP >> functions in the applicable service OAM protocol. This includes both >> Up and Down MEP functions. As shown in Figure 3, the MIP and MEP >> functions being referred to are logically located within the CE >> facing port of a PE. Down MEP functions are towards the CE. Up MEP >> functions are towards the PE forwarding mechanism. CFM between the PE >> Up MEPs is a type of EVPN Network OAM while CFM between the CEs or >> from a PE to its local CE or to the remote CE is Service OAM. >> >> So how about the following replacement wording: >> >> The EVPN PE MUST support MIP functions in the applicable service OAM >> protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP >> functions in the applicable service OAM protocol. This includes both >> Up and Down MEP functions. >> >> As shown in Figure 3, the MIP and MEP functions being referred to >> are logically located within the device's port operating at the >> customer level. (There could be MEPs/MIPs within PE ports facing >> the provider network but they would not be relevant to EVPN Service >> OAM as the traffic passing through them will be >> encapsulated/tunneled so any customer level OAM messages will just >> be treated as data.) Down MEP functions are away from the device >> while up MEP functions are towards the device (towards the PE >> forwarding mechanism in the case of a PE). OAM messages between the >> PE Up MEPs are a type of EVPN Network OAM while such messages >> between the CEs or from a PE to its local CE or to the remote CE is >> Service OAM. >> >> and perhaps adding entries for "Down MEP" and "Up MEP" in the >> Terminology section. Also the following adjusted figure 3 might show >> more clearly that the MEPs/MIPs are part of the CEs/PEs: >> >> +-------+ +----------------+ +----------------+ +-------+ >> |+-----+| |+--------------+| |+--------------+| |+-----+| >> || CE || || PE1 || ... || PE2 || || CE || >> |+--+--+| |+---+--------+-+| |+-+--------+---+| |+--+--+| >> | | | | | | | | | | | | | | >> |+--+--+| |+---+-----+ . | | . +-----+---+| |+--+--+| >> || MEP || || | Up^ | . | ... | . |Up^ | || || MEP || >> ||DownV|| ||MIP|MEP | . | | . |MEP |MIP|| ||downV|| >> |+--+--+| || |DownV| . | | . |DownV| || |+--+--+| >> | | | |+---+-----+ | | | | +-----+---+| | | | >> +---|---+ +----|--------|--+ +--|--------|----+ +---|---+ >> | | | | | | >> +------------+ +--- ... ---+ +------------+ >> >> > Sec 3.2.1 & 3.2.2. I am not sure of the extent which IPPM metrics and >> > methods >> > can apply to these layers. But there are some references that can guide >> > loss, >> > delay, and jitter measurements: >> > >> > Loss: RFC 7680, RFC 6673 >> > >> > Delay: RFC 7679, RFC 2681 >> > >> > Jitter: RFC 3393 >> > >> > I encourage the authors to peruse IPPM's published RFCs on datatracker to >> > see >> > if other documents would be similarly useful. >> >> Thanks for the references. I do not see any problem in adding these >> references for delay and jitter to Section 3.2.2 of the draft and the >> references for loss to Section 3.2.1 of the draft. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> [email protected] _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
