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

Reply via email to