Re: [bess] I-D Action: draft-ietf-bess-evpn-bfd-06.txt

[Donald Eastlake]

This is just a refresh so the draft doesn't expire before the end of
the Brisbane meeting.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Fri, Mar 1, 2024 at 11:33 AM  wrote:
>
> Internet-Draft draft-ietf-bess-evpn-bfd-06.txt is now available. It is a work
> item of the BGP Enabled ServiceS (BESS) WG of the IETF.
>
>Title:   EVPN Network Layer Fault Management
>Authors: Vengada Prasad Govindan
> Mudigonda Mallik
> Ali Sajassi
> Gregory Mirsky
> Donald E. Eastlake 3rd
>Name:draft-ietf-bess-evpn-bfd-06.txt
>Pages:   17
>Dates:   2024-03-01
>
> Abstract:
>
>This document specifies proactive, in-band network layer OAM
>mechanisms to detect loss of continuity faults that affect unicast
>and multi-destination paths (used by Broadcast, Unknown Unicast, and
>Multicast traffic) in an Ethernet VPN (RFC 7432bis) network.  The
>mechanisms specified in the draft use the widely adopted
>Bidirectional Forwarding Detection (RFC 5880) protocol and other
>protocols as necessary.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bfd/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-bfd-06.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-bfd-06
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Donald Eastlake]

I support WG adoption.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Thu, Oct 5, 2023 at 6:45 AM Matthew Bocci (Nokia)
 wrote:
>
> WG
>
>
>
> This email starts a one-week WG adoption poll for 
> draft-ietf-bess-bgp-sdwan-uasge-16 [1]
>
>
>
> A little bit of history: A previous version was adopted, completed WG last 
> call, and publication requested as an Informational RFC. v15 of this draft 
> was reviewed by the IESG and found to have a restrictive clause in the 
> boilerplate. This has now been removed, but since that clause was 
> inconsistent with the draft having been adopted as a WG document in the first 
> place, we have been asked to go through the process again.
>
>
>
> Please review the draft and post any comments to the BESS mailing list.
>
>
>
> This poll will close on Thursday 12th October.
>
>
>
> Regards
>
>
>
> Matthew
>
>
>
> [1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
> interconnected by multiple types of underlay networks owned and managed by 
> different network providers.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Donald Eastlake]

Hi Neeraj,

Yes, version -13 looks good.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Mon, Aug 21, 2023 at 1:21 PM Neeraj Malhotra (nmalhotr)
 wrote:
>
>
>
> Hi Donald,
>
>
>
> Thanks again for the additional points. I have addressed all of the 
> additional comments below in the latest rev13. Please do let me know if there 
> is any additional input before we can move further.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> From: Donald Eastlake 
> Date: Wednesday, August 16, 2023 at 10:53 AM
> To: Neeraj Malhotra (nmalhotr) 
> Cc: bess-cha...@ietf.org , 
> draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 
> , rtg-...@ietf.org 
> , BESS 
> Subject: Re: RtgDir Early review: 
> draft-ietf-bess-evpn-irb-extended-mobility-10.txt
>
> Hi Neeraj,
>
>
>
> Sorry for the delay in responding.
>
>
>
> Generally my comments have been incorporated and, I think, all my issues 
> addressed. However, some problems were introduced by the changes and there 
> are some nits:
>
> - The RFC 2119 & 8174 boilerplate language should presumably be in Section 2 
> but has disappeared from the draft.
>
> - Square bracketed references are not allowed in the Abstract. You need to 
> change those in the Abstract back to just "RFC 7432" or perhaps "RFC 7432bis".
>
> - Although in my comments I said the draft should be shown as updating "RFC 
> 7432", the Updates: line on the title page takes only numbers so it should 
> just say "7432".
>
>
>
> Also, the references to RFC 826 and RFC 4861 need the space removed at the 
> square bracketed reference in the text body and to be added to the References 
> section
>
> and you should update references:
>
> draft-ietf-bess-evpn-inter-subnet-forwarding -> RFC 9135
>
> draft-ietf-bess-evpn-proxy-arp-nd -> 9161
>
>
>
> I have no idea if the reason you state will be good enough for the IESG to 
> allow >5 authors.
>
>
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
>
>
>
>
> On Tue, Aug 15, 2023 at 4:00 PM Neeraj Malhotra (nmalhotr) 
>  wrote:
>
>
>
> Hi Donald,
>
>
>
> Rev12 of the draft also takes care of the missing note with respect to six 
> authors on the draft. Please do let me know if there is anything else beyond 
> the earlier review comments that needs to be addressed.
>
>
>
> If not, would like to request on behalf of all authors to move this forward.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> From: Neeraj Malhotra (nmalhotr) 
> Date: Tuesday, August 1, 2023 at 4:23 PM
> To: Donald Eastlake , bess-cha...@ietf.org 
> , 
> draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 
> 
> Cc: rtg-...@ietf.org , BESS 
> Subject: Re: RtgDir Early review: 
> draft-ietf-bess-evpn-irb-extended-mobility-10.txt
>
>
>
> Hi Donald,
>
>
>
> Many thanks for the details review and comments. I have published version 11 
> of the document that incorporates all of your comments. Please also see 
> inline below for some additional clarifications.
>
>
>
> This document repeatedly says that it may be considered a clarification of 
> RFC 7432. I believe it is true that the behavior specified in this document 
> is permitted by RFC 7432 but other behaviors are permitted and perhaps 
> common. In order to handle the mobility cases covered in this document the 
> behaviors in the document would have to be implemented or some other solution 
> adopted. Thus I think the title page header should show this document as 
> updating RFC 7432 and this should be mentioned in the Abstract and 
> Introduction.
>
>
>
> [NM]: Ack. I have updated the text in the abstract and introduction sections 
> to say that this document updates sequence number procedures defined in 
> [RFC7432] in addition to the title page header.
>
>
>
> It seems to me that the last paragraph of Section 7.2 ignores the case where 
> Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs under Mz 
> were currently being advertised with sequence number M where M > N. The 
> paragraph says the new Mz sequence number must be incremented to N+1 but if 
> M>N I think it must be incremented to M+1. I have suggested changes to the 
> last two paragraphs of Section 7.2 in the attached.
>
>
>
> [NM]: that’s a really good catch. A later section (8) does cover this but the 
> example in section 7.2 was missing 

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Donald Eastlake]

Hi Neeraj,

Sorry for the delay in responding.

Generally my comments have been incorporated and, I think, all my issues
addressed. However, some problems were introduced by the changes and there
are some nits:
- The RFC 2119 & 8174 boilerplate language should presumably be in Section
2 but has disappeared from the draft.
- Square bracketed references are not allowed in the Abstract. You need to
change those in the Abstract back to just "RFC 7432" or perhaps "RFC
7432bis".
- Although in my comments I said the draft should be shown as updating "RFC
7432", the Updates: line on the title page takes only numbers so it should
just say "7432".

Also, the references to RFC 826 and RFC 4861 need the space removed at the
square bracketed reference in the text body and to be added to the
References section
and you should update references:

draft-ietf-bess-evpn-inter-subnet-forwarding -> RFC 9135

draft-ietf-bess-evpn-proxy-arp-nd -> 9161


I have no idea if the reason you state will be good enough for the IESG to
allow >5 authors.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Tue, Aug 15, 2023 at 4:00 PM Neeraj Malhotra (nmalhotr) <
nmalh...@cisco.com> wrote:

>
>
> Hi Donald,
>
>
>
> Rev12 of the draft also takes care of the missing note with respect to six
> authors on the draft. Please do let me know if there is anything else
> beyond the earlier review comments that needs to be addressed.
>
>
>
> If not, would like to request on behalf of all authors to move this
> forward.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> *From: *Neeraj Malhotra (nmalhotr) 
> *Date: *Tuesday, August 1, 2023 at 4:23 PM
> *To: *Donald Eastlake , bess-cha...@ietf.org <
> bess-cha...@ietf.org>,
> draft-ietf-bess-evpn-irb-extended-mobility@ietf.org <
> draft-ietf-bess-evpn-irb-extended-mobility@ietf.org>
> *Cc: *rtg-...@ietf.org , BESS 
> *Subject: *Re: RtgDir Early review:
> draft-ietf-bess-evpn-irb-extended-mobility-10.txt
>
>
>
> Hi Donald,
>
>
>
> Many thanks for the details review and comments. I have published version
> 11 of the document that incorporates all of your comments. Please also see
> inline below for some additional clarifications.
>
>
>
> *This document repeatedly says that it may be considered a clarification
> of RFC 7432. I believe it is true that the behavior specified in this
> document is permitted by RFC 7432 but other behaviors are permitted and
> perhaps common. In order to handle the mobility cases covered in this
> document the behaviors in the document would have to be implemented or some
> other solution adopted. Thus I think the title page header should show this
> document as updating RFC 7432 and this should be mentioned in the Abstract
> and Introduction.*
>
>
>
> [NM]: Ack. I have updated the text in the abstract and introduction
> sections to say that this document updates sequence number procedures
> defined in [RFC7432] in addition to the title page header.
>
>
>
> *It seems to me that the last paragraph of Section 7.2 ignores the case
> where Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs
> under Mz were currently being advertised with sequence number M where M >
> N. The paragraph says the new Mz sequence number must be incremented to N+1
> but if M>N I think it must be incremented to M+1. I have suggested changes
> to the last two paragraphs of Section 7.2 in the attached.*
>
>
>
> [NM]: that’s a really good catch. A later section (8) does cover this but
> the example in section 7.2 was missing this condition. Updated.
>
>
>
> *Drafts should generally be worded so the text will be correct in the
> final RFC. So both occurrences of "proposed" in this draft should be
> replaced by "specified" or "defined" and occurrences of "draft" in the body
> text should be replaced with "document".*
>
>
>
> [NM] updated.
>
>
>
> *Section 2.1 lists subsequent sections as Informative or Normative but
> omits Sections 3 and 7. I think Section 3 is Informative. The right
> category for Section 7 is a bit unclear but I'm inclined towards normative.*
>
>
>
> [NM]: Updated as above – except that I am also a bit unclear if section 7
> should be listed as normative as it is doing some ground work for the
> specifications in subsequent normative sections using some examples but is
> not meant to provide a complete specification. I have left it out for now,
> but happy to include it as normative if needed.
>
>
>
> *Section 10.2 refers to section 6.1

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

[Donald Eastlake]

I support publication.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Mon, Sep 26, 2022 at 7:05 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> This email starts a two-week working group last call for 
> draft-ietf-bess-bgp-sdwan-usage-05
> [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as an Informational RFC.
>
>
>
> This poll runs until the 10th October 2022
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The document won't progress without answers from
> all the authors and contributors.
>
> There are currently two IPR disclosures.
>
>
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
>
>
> [1]  draft-ietf-bess-bgp-sdwan-usage-05
> 
>
>
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: (with DISCUSS and COMMENT)

[Donald Eastlake]

Revision -10 just posted has only this change (and the version and
dates bumped).

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Thu, Apr 15, 2021 at 7:24 PM John Scudder  wrote:
>
> Works for me. Thanks for the additional discussion.
>
> —John
>
> > On Apr 15, 2021, at 6:35 PM, Donald Eastlake  wrote:
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi John,
> >
> >> On Thu, Apr 15, 2021 at 5:40 PM John Scudder  wrote:
> >> Hi Donald,
> >>
> >>> On Apr 15, 2021, at 1:19 PM, Donald Eastlake  wrote:
> >>> Hi John,
> >>>
> >>> First, an aside: RECOMMEND really isn't the same as SHOULD no
> >>> matter what the RFCs say. As any native English speaker knows,
> >>> "recommend" is weaker than "should" and pretty much everyone,
> >>> including ADs, usually treats it as such. I pretty regularly see AD
> >>> comments about how "should" is almost "must" and authors need to
> >>> say something about when you can violate the "should" etc. On the
> >>> other hand, while I'm sure it has happened, I don't recall ever
> >>> seeing such comments about "recommend". So I think the RFCs should
> >>> be adjusted to correspond to actual practice. But, of course, none
> >>> of this has anything to do with what you want to talk about.
> >>
> >>
> >> I look forward to your draft to update RFC 2119!
> >>
> >>> How about:
> >>>
> >>> EVPN Network OAM mechanisms MUST provide in-band monitoring
> >>> capabilities. Such OAM messages SHOULD be encoded so that they
> >>> exhibit similar characteristics to data traffic in order maximize
> >>> the fate sharing between OAM and data: they SHOULD have a similar
> >>> distribution of packet lengths, header fields and flags SHOULD
> >>> have the value or values present in data packets, and bit patterns
> >>> in much of the OAM packets should be similar to data. However this
> >>> might not all be possible or practical: Delivery of OAM traffic to
> >>> nodes that will erroneously process it as data intended for that
> >>> node is normally worse that deviation from congruence with data;
> >>> furthermore, there will be restrictions for proper processing of
> >>> OAM typically including minimum length and value of some header
> >>> field or flag that require some deviation from data; and, some
> >>> characteristics of data flows that are or will be encountered may
> >>> be unpredictable making it impossible or impractical to adjust OAM
> >>> packets as herein advised.
> >>
> >> Let me be blunt: do you need to say anything at all about this? As
> >> far as I can tell the additional words didn’t make it any easier for
> >> an implementer to write their code, or for a customer to tell if the
> >> implementation complies with the RFC-to-be.
> >
> > I agree.
> >
> >> “To the extent practicable, it is desirable for OAM messages to
> >> share fate with data. Details of how to achieve this are beyond the
> >> scope of this document.”  ??
> >
> > Something close to that is fine with me. I think it should refer to
> > "OAM test messages" or the like -- I don't think this applies exactly
> > to OAM control messages. So I would say
> >
> >"It is desirable, to the extent practical, for OAM test messages
> >to share fate with data messages. Details of how to achieve this
> >are beyond the scope of this document."
> >
> > Thanks,
> > Donald
> > =
> > Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > 2386 Panoramic Circle, Apopka, FL 32703 USA
> > d3e...@gmail.com
> >
> >> Thanks,
> >>
> >> —John
> >>
> >>> Thanks,
> >>> Donald >
> >>> === >  Donald E. Eastlake 3rd
> >>> +1-508-333-2270 (cell) >  2386 Panoramic Circle, Apopka, FL 32703
> >>> USA >  d3e...@gmail.com > > Thanks, > Donald >
> >>> ===
> >> Donald E. Eastlake 3rd
> >>> +1-508-333-2270 (cell)
> >> 2386 Panoramic Circle, Apopka, FL 32703 USA
> >> d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi John,

On Thu, Apr 15, 2021 at 5:40 PM John Scudder  wrote:
> Hi Donald,
>
> On Apr 15, 2021, at 1:19 PM, Donald Eastlake  wrote:
>> Hi John,
>>
>> First, an aside: RECOMMEND really isn't the same as SHOULD no
>> matter what the RFCs say. As any native English speaker knows,
>> "recommend" is weaker than "should" and pretty much everyone,
>> including ADs, usually treats it as such. I pretty regularly see AD
>> comments about how "should" is almost "must" and authors need to
>> say something about when you can violate the "should" etc. On the
>> other hand, while I'm sure it has happened, I don't recall ever
>> seeing such comments about "recommend". So I think the RFCs should
>> be adjusted to correspond to actual practice. But, of course, none
>> of this has anything to do with what you want to talk about.
>
>
> I look forward to your draft to update RFC 2119!
>
>> How about:
>>
>>  EVPN Network OAM mechanisms MUST provide in-band monitoring
>>  capabilities. Such OAM messages SHOULD be encoded so that they
>>  exhibit similar characteristics to data traffic in order maximize
>>  the fate sharing between OAM and data: they SHOULD have a similar
>>  distribution of packet lengths, header fields and flags SHOULD
>>  have the value or values present in data packets, and bit patterns
>>  in much of the OAM packets should be similar to data. However this
>>  might not all be possible or practical: Delivery of OAM traffic to
>>  nodes that will erroneously process it as data intended for that
>>  node is normally worse that deviation from congruence with data;
>>  furthermore, there will be restrictions for proper processing of
>>  OAM typically including minimum length and value of some header
>>  field or flag that require some deviation from data; and, some
>>  characteristics of data flows that are or will be encountered may
>>  be unpredictable making it impossible or impractical to adjust OAM
>>  packets as herein advised.
>
> Let me be blunt: do you need to say anything at all about this? As
> far as I can tell the additional words didn’t make it any easier for
> an implementer to write their code, or for a customer to tell if the
> implementation complies with the RFC-to-be.

I agree.

> “To the extent practicable, it is desirable for OAM messages to
> share fate with data. Details of how to achieve this are beyond the
> scope of this document.”  ??

Something close to that is fine with me. I think it should refer to
"OAM test messages" or the like -- I don't think this applies exactly
to OAM control messages. So I would say

"It is desirable, to the extent practical, for OAM test messages
to share fate with data messages. Details of how to achieve this
are beyond the scope of this document."

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

>  Thanks,
>
> —John
>
>> Thanks,
>> Donald >
>> === >  Donald E. Eastlake 3rd
>> +1-508-333-2270 (cell) >  2386 Panoramic Circle, Apopka, FL 32703
>> USA >  d3e...@gmail.com > > Thanks, > Donald >
>>  ===
>  Donald E. Eastlake 3rd
>>  +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi John,

First, an aside: RECOMMEND really isn't the same as SHOULD no matter what
the RFCs say. As any native English speaker knows, "recommend" is weaker
than "should" and pretty much everyone, including ADs, usually treats it as
such. I pretty regularly see AD comments about how "should" is almost
"must" and authors need to say something about when you can violate the
"should" etc. On the other hand, while I'm sure it has happened, I don't
recall ever seeing such comments about "recommend". So I think the RFCs
should be adjusted to correspond to actual practice. But, of course, none
of this has anything to do with what you want to talk about.


How about:

EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities.
Such OAM messages SHOULD be encoded so that they exhibit similar
characteristics to data traffic in order maximize the fate sharing between
OAM and data: they SHOULD have a similar distribution of packet lengths,
header fields and flags SHOULD have the value or values present in data
packets, and bit patterns in much of the OAM packets should be similar to
data. However this might not all be possible or practical: Delivery of OAM
traffic to nodes that will erroneously process it as data intended for that
node is normally worse that deviation from congruence with data;
furthermore, there will be restrictions for proper processing of OAM
typically including minimum length and value of some header field or flag
that require some deviation from data; and, some characteristics of data
flows that are or will be encountered may be unpredictable making it
impossible or impractical to adjust OAM packets as herein advised.


Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Tue, Apr 13, 2021 at 1:30 PM John Scudder  wrote:

> Donald,
>
> It being an AD’s prerogative to change his mind :-/ I’d like to discuss
> (if not necessarily DISCUSS, yet) this some more.
>
> Let’s remember what SHOULD means:
>
> 3 <https://tools.ietf.org/html/rfc2119#section-3>. SHOULD   This word, or the 
> adjective "RECOMMENDED", mean that there
>may exist valid reasons in particular circumstances to ignore a
>particular item, but the full implications must be understood and
>carefully weighed before choosing a different course.
>
>
> It’s basically a MUST with caveats, it doesn’t mean “try your best but if
> you can’t, oh well." Your new text is
>
> EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities.
>> OAM messages SHOULD be encoded so that they exhibit similar entropy
>> characteristics to data traffic in order maximize the fate sharing between
>> OAM and data.
>>
>>
> I’m now scratching my head and wondering how, as an implementor, I’m
> supposed to do this and what the “particular circumstances” are that allow
> me to not do it. If the text just means “gee, it would be awful nice if the
> implementor can figure this out, but if not oh well”, then at the very
> least I think the 2119 keyword isn’t justified, and the language could be
> softened even further as in “It’s desirable for OAM messages to be encoded
> so that…” But that’s so soft, that maybe even better would be to simply
> state that fate-sharing is out of scope (if the authors really can’t
> provide specifics on how to do it).
>
> On the other hand, if you (and your co-authors) *are* able to be more
> specific, then of course the sentence could be replaced with more detailed
> recommendations. The proof of the pudding would be that I SHOULD ;-) be
> able to look at your text and say “ok if I’m using VXLAN then I should set
> the fields in the OAM packet to thus-and-such”. But right now, I think it’s
> neither fish nor fowl.
>
> Thanks,
>
> —John
>
> On Apr 13, 2021, at 10:41 AM, John Scudder <
> jgs=40juniper@dmarc.ietf.org> wrote:
>
> Thanks, Donald. I agree that my discuss and comments are fixed by -09.
>
> —John
>
> On Apr 12, 2021, at 9:08 PM, Donald Eastlake  wrote:
>
>
>
> Hi John,
>
> I've posted -09 which should resolve your DISCUSS and COMMENTs.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
>
> On Mon, Apr 12, 2021 at 1:38 PM John Scudder  wrote:
>
>> Thanks for hopping threads, I shoulda caught that last one. Your proposed
>> change looks fine, I’ll remove my DISCUSS in anticipati

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi Rob,

I have posted a -09 revision which should resolve your COMMENTs.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Sat, Apr 10, 2021 at 6:58 AM Rob Wilton (rwilton) 
wrote:

> Hi Donald,
>
> Copying Martin for the 802.1Q normative reference question.
>
> Please see inline.
>
> > -Original Message-
> > From: Donald Eastlake 
> > Sent: 08 April 2021 22:08
> > To: Rob Wilton (rwilton) 
> > Cc: The IESG ;
> draft-ietf-bess-evpn-oam-req-fr...@ietf.org;
> > bess-cha...@ietf.org; BESS ; Matthew Bocci
> > 
> > Subject: Re: Robert Wilton's No Objection on
> draft-ietf-bess-evpn-oam-req-
> > frmwk-08: (with COMMENT)
> >
> > Hi Rob,
> >
> > On Thu, Apr 8, 2021 at 9:36 AM Robert Wilton via Datatracker
> >  wrote:
> > >
> > > Robert Wilton has entered the following ballot position for
> > > draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
> > >
> > >...
> > >
> > > --
> > > COMMENT:
> > > --
> > >
> > > Hi,
> > >
> > > Thanks for this document.
> > >
> > > It's a bit unclear to me whether the descriptions/definitions of
> > MIP/MEP/MA/MD
> > > are coming from CFM or RFC 6136.  Section 1.1 suggests that they are
> > coming
> > > from CFM (but without a normative reference to 802.1Q), but the
> > terminology
> > > implies that they are being taken from RFC 6136.
> >
> > Although I have tweaked them a bit, the descriptions/definitions were
> > in the draft when I took up the pen along with the reference to RFC
> > 6136. So I don't know where they came from. Surely the important thing
> > is their accuracy.
> [RW]
>
> I guess I feel that subsequent parts of the document assume a more
> detailed understanding of what MIPS/MEPS are than is described in the
> terminology.  This is fine, and I don't think that further text in the
> terminology is required, but it was unclear to me, that if a reader wanted
> to better understand what is meant by these terms whether they should be
> looking at RFC 6136 or 802.1Q, and I was hoping that the document could
> clarify/choose a definitive source reference.
>
> My impression, given how they are used, is that a reference to 802.1Q for
> CFM is probably most useful.
>
>
> >
> > >  Certainly, there seem to be places in this document where more meaning
> > of
> > >  these terms seems to be expected than what is provided in the
> > terminology
> > >  section.   Section 2.6 refers to CCMs, but I think that a reader would
> > only
> > >  understand what these are if they have read CFM.  Hence, I think that
> > this
> > >  document would probably benefit from having a normative reference to
> > 802.1Q
> > >  rather than informative.
> >
> > I have no problem with adding more references to 802.1Q but would
> > moving 802.1Q from Informational to Normative require a new Last Call
> > since it is not an IETF Standards Track document?
> [RW]
> Yes, I think that would be required.  But I've not raised this as a
> discuss level concern so will defer to the responsible AD here.
>
>
>
> >
> > > Minor comments:
> > >
> > > 2.1 OAM Layering
> > >
> > > "and shows which devices have visibility into what OAM layer(s)."
> > >
> > > Perhaps indicate by the 'o' symbol. Otherwise the fact that the Link
> OAM
> > is the
> > > end point of the physical links, whereas the other OAM endpoints are
> may
> > cause
> > > confusion.
> >
> > I'm not sure exactly what you are saying. The ends of the Link OAM
> > correspond to the ports. The other types of OAM generally run between
> > the central control planes of the nodes.
> [RW]
>
> > Do you want me to add
> > something to the text about the 'o' symbols? ("and, as indicated by
> > where the "o"s line up, shows which devices have visibility into what
> > OAM layer(s).") Or what?
> [RW]
>
> Yes, this is what I was suggesting, but it is at the authors' discretion.
>
>
> >
> > > Figure 2:
> >
> > While I tried to give some hints in the details of this Figure, in
> > some of your comments below I think you are trying to read way too
> > much into fine details of this ve

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi Eric,

I have posted revision -09 which should resolve your COMMENTs except
possible that I decided not to include a statement that EVPN OAM MAY use
IOAM or the like. As I say, there are lots of things it MAY use...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Thu, Apr 8, 2021 at 8:53 PM Donald Eastlake  wrote:

> Hi Eric,
>
> On Thu, Apr 8, 2021 at 2:36 AM Eric Vyncke (evyncke) 
> wrote:
> > Donald,
> >
> > Thank you for your reply as well as for answering all the questions. I
> like your suggestion about MA/MEP/MIP.
> >
> > About the last point (synthetic traffic or iOAM), while I understand the
> point that OAM should work in the absence of actual traffic (pretty obvious
> indeed), I am still ambivalent whether this document should only be about
> synthetic traffic without being open to other OAM techniques.
>
> Well, I don't think there is anything in the document prohibiting or
> recommending against using, for example, IOAM. I suppose a statement
> could be added saying that it MAY be used, but then there are a lot of
> things that may be used...
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
> > Regards
> >
> > -éric
> >
> > -Original Message-
> > From: Donald Eastlake 
> > Date: Thursday, 8 April 2021 at 00:05
> > To: Eric Vyncke 
> > Cc: The IESG , "
> draft-ietf-bess-evpn-oam-req-fr...@ietf.org" <
> draft-ietf-bess-evpn-oam-req-fr...@ietf.org>, "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, BESS , Matthew Bocci <
> matthew.bo...@nokia.com>
> > Subject: Re: Éric Vyncke's No Objection on
> draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)
> >
> > Hi Éric,
> >
> > On Wed, Apr 7, 2021 at 4:14 AM Éric Vyncke via Datatracker
> >  wrote:
> > >
> > > Éric Vyncke has entered the following ballot position for
> > > draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
> > >
> > > ...
> > >
> > >
> --
> > > COMMENT:
> > >
> --
> > >
> > > Thank you for the work put into this document.
> > >
> > > Please find below some non-blocking COMMENT points (but replies
> would be
> > > appreciated).
> > >
> > > I hope that this helps to improve the document,
> > >
> > > Regards,
> > > -éric
> > >
> > > == COMMENTS ==
> > >
> > > Minor regret for a doc shepherd write-up, which is dated 9 months
> ago...
> > >
> > > -- Section 1 --
> > > Introducing C-MAC and B-MAC could be useful for the reader.
> >
> > C-MAC is Customer/Client MAC address and B-MAC is Backbone MAC
> address
> > as further specified in RFC 7623. These can be spelled out and a
> > reference to RFC 7623 (which is already listed in the References for
> > this draft) added.
> >
> > > -- Section 1.3 --
> > > Slighlty puzzled by MA/MEP/MIP as those are only about the M of
> OAM. Should
> > > those be OAMA, OAMEP, OAMIP ? Or at least should there be some
> explanations ?
> >
> > MA/MEP/MIP are all terms used in CFM (Connectivity Fault Management)
> > which is specified in 802.1Q. There could be some wording adjustment
> > to clarify this. For example, saying that they are "part of" Service
> > OAM rather than implying they might be all of it.
> >
> > > -- Section 2.2 --
> > > I must confess my lack of knowledge about CFM frames but I am
> puzzled by
> > > "snooping on CFM frames and advertising them to remote PEs as a
> MAC/IP" 1) if
> > > the CFM frame are not IP, then how can it be advertised in a
> MAC/IP ? (i.e.,
> > > the CE may not use IP at all) 2) if the CFM frame are IP, then
> which version of
> > > IP ? and how to recognize them ? Or did I miss something obvious ?
> >
> > CFM frames are not IP. However, the EVPN MAC/IP Advertisement route
> is
> > quite flexible and includes a length for the IP address. As stated in
> > RFC 7432 "By default, the IP Address Length fi

Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi John,

I've posted -09 which should resolve your DISCUSS and COMMENTs.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Mon, Apr 12, 2021 at 1:38 PM John Scudder  wrote:

> Thanks for hopping threads, I shoulda caught that last one. Your proposed
> change looks fine, I’ll remove my DISCUSS in anticipation of you issuing a
> new version. (One nit on your new text, “in order maximize” should be “in
> order to maximize”.)
>
> —John
>
> On Apr 12, 2021, at 1:03 PM, Donald Eastlake  wrote:
>
>
> [External Email. Be cautious of content]
>
>
> Hi,
>
> On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker <
> nore...@ietf.org> wrote:
> >
> > John Scudder has entered the following ballot position for
> > draft-ietf-bess-evpn-oam-req-frmwk-08: Discuss
> >
> > ...
> >
> > --
> > DISCUSS:
> > --
> >
> > Section 2.3:
> >
> >EVPN Network OAM mechanisms MUST provide in-band monitoring
> >capabilities. As such, OAM messages MUST be encoded so that they
> >exhibit identical entropy characteristics to data traffic in order
> >that they share the same fate.
> >
> > It’s not obvious to me what you mean by “identical entropy
> characteristics to
> > data traffic”. Surely, different flows may have different entropy
> > characteristics, so, *which* data traffic? Similarly, with which data
> traffic
> > are you saying the OAM messages must share fate?
>
> I guess when you changed your COMMENT to a DISCUSS it creates a new thread
> so I should reply here as I did to this when it was a COMMENT:
>
> How about something more like:
>
> EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities.
> OAM messages SHOULD be encoded so that they exhibit similar entropy
> characteristics to data traffic in order maximize the fate sharing between
> OAM and data.
>
>
> > --
> > COMMENT:
> > --
> >
> > Thanks for the clear and readable document. I have one nit and one
> question.
> >
> > 1. Section 1, nit:
> >
> > “EVPN is an Layer 2” s/an/a/
>
> OK.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-09.txt

[Donald Eastlake]

This revision has changes to resolve IESG comments and one DISCUSS,

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Mon, Apr 12, 2021 at 5:27 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : EVPN Operations, Administration and Maintenance
> Requirements and Framework
> Authors : Samer Salam
>   Ali Sajassi
>   Sam Aldrin
>   John E. Drake
>   Donald E. Eastlake
> Filename: draft-ietf-bess-evpn-oam-req-frmwk-09.txt
> Pages   : 21
> Date: 2021-04-12
>
> Abstract:
>This document specifies the requirements and reference framework for
>Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
>The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider
>Backbone Bridge EVPN).  The framework defines the layered OAM model
>encompassing the EVPN service layer, network layer, underlying Packet
>Switched Network (PSN) transport layer, and link layer but focuses on
>the service and network layers.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-09
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-09
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi Eric,

On Thu, Apr 8, 2021 at 2:36 AM Eric Vyncke (evyncke)  wrote:
> Donald,
>
> Thank you for your reply as well as for answering all the questions. I like 
> your suggestion about MA/MEP/MIP.
>
> About the last point (synthetic traffic or iOAM), while I understand the 
> point that OAM should work in the absence of actual traffic (pretty obvious 
> indeed), I am still ambivalent whether this document should only be about 
> synthetic traffic without being open to other OAM techniques.

Well, I don't think there is anything in the document prohibiting or
recommending against using, for example, IOAM. I suppose a statement
could be added saying that it MAY be used, but then there are a lot of
things that may be used...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> Regards
>
> -éric
>
> -Original Message-
> From: Donald Eastlake 
> Date: Thursday, 8 April 2021 at 00:05
> To: Eric Vyncke 
> Cc: The IESG , "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
> , "bess-cha...@ietf.org" 
> , BESS , Matthew Bocci 
> 
> Subject: Re: Éric Vyncke's No Objection on 
> draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)
>
> Hi Éric,
>
> On Wed, Apr 7, 2021 at 4:14 AM Éric Vyncke via Datatracker
>  wrote:
> >
> > Éric Vyncke has entered the following ballot position for
> > draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
> >
> > ...
> >
> > --
> > COMMENT:
> > --
> >
> > Thank you for the work put into this document.
> >
> > Please find below some non-blocking COMMENT points (but replies would be
> > appreciated).
> >
> > I hope that this helps to improve the document,
> >
> > Regards,
> > -éric
> >
> > == COMMENTS ==
> >
> > Minor regret for a doc shepherd write-up, which is dated 9 months ago...
> >
> > -- Section 1 --
> > Introducing C-MAC and B-MAC could be useful for the reader.
>
> C-MAC is Customer/Client MAC address and B-MAC is Backbone MAC address
> as further specified in RFC 7623. These can be spelled out and a
> reference to RFC 7623 (which is already listed in the References for
> this draft) added.
>
> > -- Section 1.3 --
> > Slighlty puzzled by MA/MEP/MIP as those are only about the M of OAM. 
> Should
> > those be OAMA, OAMEP, OAMIP ? Or at least should there be some 
> explanations ?
>
> MA/MEP/MIP are all terms used in CFM (Connectivity Fault Management)
> which is specified in 802.1Q. There could be some wording adjustment
> to clarify this. For example, saying that they are "part of" Service
> OAM rather than implying they might be all of it.
>
> > -- Section 2.2 --
> > I must confess my lack of knowledge about CFM frames but I am puzzled by
> > "snooping on CFM frames and advertising them to remote PEs as a MAC/IP" 
> 1) if
> > the CFM frame are not IP, then how can it be advertised in a MAC/IP ? 
> (i.e.,
> > the CE may not use IP at all) 2) if the CFM frame are IP, then which 
> version of
> > IP ? and how to recognize them ? Or did I miss something obvious ?
>
> CFM frames are not IP. However, the EVPN MAC/IP Advertisement route is
> quite flexible and includes a length for the IP address. As stated in
> RFC 7432 "By default, the IP Address Length field is set to 0, and the
> IP Address field is omitted from the route." If you do know an IP
> address and want to advertise it, then the length is 32 or 128, as
> appropriate, and the IP address is included.
>
> > -- Section 3.1.2.1 --
> > Does this section cover OAM designed by other WG ? E.g.,
> > draft-ietf-ippm-ioam-data or draft-ietf-6man-ipv6-alt-mark
> >
> > -- Section 3.2.1 --
> > Mostly the same comment as for 3.1.2.1, this section is only about 
> synthetic
> > traffic injection.
>
> EVPN Network OAM could include OAM designed by other WGs including
> ioam. However, in my opinion the mandatory capabilities should be
> available even in the absence of real traffic.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Zaheduzzaman Sarker's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

I believe we are in agreement on resolutions of all your comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Thu, Apr 8, 2021 at 3:29 AM Zaheduzzaman Sarker
 wrote:
>
> Hi,
>
> Thanks for the responses. Please see inline below.
>
> BR
> Zahed
>
> On 2021-04-07, 20:21, "Donald Eastlake"  wrote:
>
> Thanks for your comments. See below.
>
> On Wed, Apr 7, 2021 at 1:02 PM Zaheduzzaman Sarker via Datatracker
>  wrote:
> >
> > Zaheduzzaman Sarker has entered the following ballot position for
> > draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
> >
> > ...
> >
> > --
> > COMMENT:
> > --
> >
> > Thanks for the document and thanks to David Black for TSVART review.
> >
> > Nits/comments:
> >
> >  * P-MAC and C-MAC are these defined somewhere else? References would 
> be nice
> >  here.
>
> P-MAC does not occur in the draft; I think you mean B-MAC. C-MAC is
> Customer/Client MAC address and B-MAC is Backbone MAC address as
> further specified in RFC 7623. These can be spelled out and a
> reference to RFC 7623 (which is already listed in the References for
> the draft) added.
>
> Yes, I meant B-MAC and C-MAC . And yes spelling out and reference will be 
> helpful.
>
> >  * Section 1.3,  Section 2.1 and Section 2.2 describes P nodes in 
> different
> >  ways and that has created confusion to me. Can this be well defined in 
> the
> >  terminology section once and just be used in other place?
>
> OK, except I think it should be spelled out on first use in 2.1. But
> certainly the wording should be parallel in these cases.
>
> >  * Section 2.5 : "[802.3]" is this supposed to be a reference? it leads 
> to
> >  nowhere.
>
> Yes, it is intended to be reference to IEEE Std 802.3-2015 (or
> whatever the most recent version is). I have no idea why the nits
> checker doesn't complain about this being missing from the References
> sections. If it did, it would already have been fixed. Since this is
> just an example, I think it can be added as an Informational
> Reference.
> OK.
>
> >  * Section 3.1.1.2.1 : first time encountered "network management 
> station
> >  (NMS)", if this document is not introducing it then I would suggest to 
> at this
> >  to section 1.3 and add some descriptive texts, otherwise define it.
>
> Would it be sufficient to add an entry in the terminology section
> (1.3) and a reference to RFC 6623?
>
> Yes, that will do.
>
> >  * Section 3.1.2.1 : would be nice to expand MTU.
>
> Sure.
>
> >  * Section 3.2.1: I  can't really parse - "EVPN Network OAM SHOULD 
> provide
> >  mechanisms for measuring packet loss for a given service [RFC7680] 
> [RFC6673]."
> >  are these IPPM mechanisms recommended to be used for EVPN networks? or 
> are
> >  those merely examples?
>
> These are examples.
>
> In that case, I would suggest to rephrase the sentence to be clear that those 
> are examples.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi,

On Wed, Apr 7, 2021 at 10:28 PM Roman Danyliw via Datatracker
 wrote:
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
>
> ..
>
> --
> COMMENT:
> --
>
> Thank you to Melinda Shore for the SECDIR review.
>
> Section 4.  Since Section 2.2 described a process where the “EVPN PE MUST 
> learn
> the MAC address of locally attached CE MEPs by snooping on CFM frames ...”, is
> there is reason not to add the DoS caution from [RFC4762] of “Some means to
> limit the number of MAC addresses ... that a PE can learn SHOULD be
> implemented.”

I believe that sentence should be "EVPN PE MUST, by default, learn the
MAC address of locally attached CE MEPs by ..."

I don't see any problem with adding "Some means to limit the number of
MAC addresses that a PE will learn SHOULD be implemented."

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi,

On Thu, Apr 8, 2021 at 2:29 AM Murray Kucherawy via Datatracker
 wrote:
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Might be helpful to expand C-MAC and B-MAC on first use.

OK.

> "MD" appears in your Terminology section, but nowhere else in the document.

Well, Maintenance Domain is used in the definition of MA in the
Terminology section so I'll add an "(MD)" there.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi Rob,

On Thu, Apr 8, 2021 at 9:36 AM Robert Wilton via Datatracker
 wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
>
>...
>
> --
> COMMENT:
> --
>
> Hi,
>
> Thanks for this document.
>
> It's a bit unclear to me whether the descriptions/definitions of MIP/MEP/MA/MD
> are coming from CFM or RFC 6136.  Section 1.1 suggests that they are coming
> from CFM (but without a normative reference to 802.1Q), but the terminology
> implies that they are being taken from RFC 6136.

Although I have tweaked them a bit, the descriptions/definitions were
in the draft when I took up the pen along with the reference to RFC
6136. So I don't know where they came from. Surely the important thing
is their accuracy.

>  Certainly, there seem to be places in this document where more meaning of
>  these terms seems to be expected than what is provided in the terminology
>  section.   Section 2.6 refers to CCMs, but I think that a reader would only
>  understand what these are if they have read CFM.  Hence, I think that this
>  document would probably benefit from having a normative reference to 802.1Q
>  rather than informative.

I have no problem with adding more references to 802.1Q but would
moving 802.1Q from Informational to Normative require a new Last Call
since it is not an IETF Standards Track document?

> Minor comments:
>
> 2.1 OAM Layering
>
> "and shows which devices have visibility into what OAM layer(s)."
>
> Perhaps indicate by the 'o' symbol. Otherwise the fact that the Link OAM is 
> the
> end point of the physical links, whereas the other OAM endpoints are may cause
> confusion.

I'm not sure exactly what you are saying. The ends of the Link OAM
correspond to the ports. The other types of OAM generally run between
the central control planes of the nodes. Do you want me to add
something to the text about the 'o' symbols? ("and, as indicated by
where the "o"s line up, shows which devices have visibility into what
OAM layer(s).") Or what?

> Figure 2:

While I tried to give some hints in the details of this Figure, in
some of your comments below I think you are trying to read way too
much into fine details of this very high level diagram.

>  - Would it be helpful to move the 'o' marks to the end of the PE devices, to
>  line up with the Link OAM end points?
>
>  - Is "Service CFM" the right term here?  Does this mean "Service OAM - CFM"?

Probably should be "CFM (Service OAM)" and the PE "o" marks for it
should be moved to line up with the CE facing edge of the PE since
those ports are what are involved. Network OAM, such as BFD, logically
runs between central control planes of the PEs so having the "o"
centrally under the PE seems best to me.

>  - Probably helpful to add an informative reference to 802.3 Link OAM, which 
> is
>  in figure 2.

OK, that can be made into a reference.

> 2.2 EVPN Service OAM
>
> - I'm not sure how clear "towards the device" is when the point is already
> within the device.

How about "towards the core of the device"? A port is one the edge of
a device so I think that saying it is "within the device" has a
slightly wrong connotation.

If you have two devices with 4 ports as follows:
  P1-Dev1-P2--P3-Dev2-P4
CFM permits you to run tests between P1 and P2 or between P3 and P4
that test the continuity through and switching fabric of the devices
without using a link. Of course, you can also run tests from P1 to P3
or P2 to P3 or P1 to P4 or whatever. (Not all implementations of CFM
actually do all this. Some implement the MEPs/MIPs as virtual MEPs/MPs
in the ports that are actually implemented in the central control
plane of the device.)

> - The up and down arrows for the MEPS ("^" and "V") seem to potentially make
> Figure 3 more confusing.  Also "down" should be changed to "Down" in the last
> CE.

OK on the case change. So, on the ASCII art arrow heads, you think I
should just delete them?

> Nits:
>
> I'm not sure why the PE nodes are numbered by CE nodes are not.

Since these numbers are never used in the text, I'm inclined to eliminate them.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> Regards,
> Rob

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi John,

On Wed, Apr 7, 2021 at 10:02 PM John Scudder  wrote:
> Hi Donald,
>
> Thanks for your reply.
>
> On Apr 7, 2021, at 9:22 PM, Donald Eastlake  wrote:
>
> ...
>
> 2. Section 2.3:
>
>EVPN Network OAM mechanisms MUST provide in-band monitoring
>capabilities. As such, OAM messages MUST be encoded so that they
>exhibit identical entropy characteristics to data traffic in order
>that they share the same fate.
>
> It’s not obvious to me what you mean by “identical entropy
characteristics to
> data traffic”. Surely, different flows may have different entropy
> characteristics, so, *which* data traffic? Similarly, with which data
traffic
> are you saying the OAM messages must share fate?
>
>
> Well, it depends on what is meant by "characteristics". I believe the
>intent is to say that with a sufficient quantity of OAM messages, all
>paths used by actual data will be exercised.
>
>
> Your explanation (“all paths… will be exercised”) seems inconsistent with
§3.1.1.1:
>
>- all paths. For MPLS/IP networks with ECMP, monitoring of all
>  unicast paths between MEPs (on non-adjacent nodes) may not be
>  possible, since the per-hop ECMP hashing behavior may yield
>  situations where it is impossible for a MEP to pick flow entropy
>  characteristics that result in exercising the exhaustive set of
>  ECMP paths. Monitoring of all ECMP paths between MEPs (on non-
>  adjacent nodes) is not a requirement for EVPN OAM.
>
> Even if the above somehow isn't the issue it appears to be, I think it’s
evident that the §2.3 text in question isn’t unambiguous enough to have a
MUST applied to it, I think this needs to be rectified in some way. I’m
going to switch my ballot to a DISCUSS until we’ve resolved this.
>
> (Now that I’m looking at the §2.3 text again, “identical” bugs me too,
since identity is a much stronger requirement than, say, similarity. But
since I suspect the text will be rewritten anyway it’s not worth dwelling
on.)

Geez, here I put this text, which I inherited when I became pen holder
after draft-salam-l2vpn-evpn-oam-req-frmwk, in the best possible light and
you still object !  :-)

 OK, how about something more like:

EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities.
OAM messages SHOULD be encoded so that they exhibit similar entropy
characteristics to data traffic in order maximize the fate sharing between
OAM and data.


 Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> Thanks,
>
> —John
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi John,

Thanks for the comments, see below.

On Wed, Apr 7, 2021 at 5:53 PM John Scudder via Datatracker
 wrote:
>
> John Scudder has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Thanks for the clear and readable document. I have one nit and one question.
>
> 1. Section 1, nit:
>
> “EVPN is an Layer 2” s/an/a/

OK.

> 2. Section 2.3:
>
>EVPN Network OAM mechanisms MUST provide in-band monitoring
>capabilities. As such, OAM messages MUST be encoded so that they
>exhibit identical entropy characteristics to data traffic in order
>that they share the same fate.
>
> It’s not obvious to me what you mean by “identical entropy characteristics to
> data traffic”. Surely, different flows may have different entropy
> characteristics, so, *which* data traffic? Similarly, with which data traffic
> are you saying the OAM messages must share fate?

Well, it depends on what is meant by "characteristics". I believe the
intent is to say that with a sufficient quantity of OAM messages, all
paths used by actual data will be exercised.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Hi Éric,

On Wed, Apr 7, 2021 at 4:14 AM Éric Vyncke via Datatracker
 wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated).
>
> I hope that this helps to improve the document,
>
> Regards,
> -éric
>
> == COMMENTS ==
>
> Minor regret for a doc shepherd write-up, which is dated 9 months ago...
>
> -- Section 1 --
> Introducing C-MAC and B-MAC could be useful for the reader.

C-MAC is Customer/Client MAC address and B-MAC is Backbone MAC address
as further specified in RFC 7623. These can be spelled out and a
reference to RFC 7623 (which is already listed in the References for
this draft) added.

> -- Section 1.3 --
> Slighlty puzzled by MA/MEP/MIP as those are only about the M of OAM. Should
> those be OAMA, OAMEP, OAMIP ? Or at least should there be some explanations ?

MA/MEP/MIP are all terms used in CFM (Connectivity Fault Management)
which is specified in 802.1Q. There could be some wording adjustment
to clarify this. For example, saying that they are "part of" Service
OAM rather than implying they might be all of it.

> -- Section 2.2 --
> I must confess my lack of knowledge about CFM frames but I am puzzled by
> "snooping on CFM frames and advertising them to remote PEs as a MAC/IP" 1) if
> the CFM frame are not IP, then how can it be advertised in a MAC/IP ? (i.e.,
> the CE may not use IP at all) 2) if the CFM frame are IP, then which version 
> of
> IP ? and how to recognize them ? Or did I miss something obvious ?

CFM frames are not IP. However, the EVPN MAC/IP Advertisement route is
quite flexible and includes a length for the IP address. As stated in
RFC 7432 "By default, the IP Address Length field is set to 0, and the
IP Address field is omitted from the route." If you do know an IP
address and want to advertise it, then the length is 32 or 128, as
appropriate, and the IP address is included.

> -- Section 3.1.2.1 --
> Does this section cover OAM designed by other WG ? E.g.,
> draft-ietf-ippm-ioam-data or draft-ietf-6man-ipv6-alt-mark
>
> -- Section 3.2.1 --
> Mostly the same comment as for 3.1.2.1, this section is only about synthetic
> traffic injection.

EVPN Network OAM could include OAM designed by other WGs including
ioam. However, in my opinion the mandatory capabilities should be
available even in the absence of real traffic.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Zaheduzzaman Sarker's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Donald Eastlake]

Thanks for your comments. See below.

On Wed, Apr 7, 2021 at 1:02 PM Zaheduzzaman Sarker via Datatracker
 wrote:
>
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Thanks for the document and thanks to David Black for TSVART review.
>
> Nits/comments:
>
>  * P-MAC and C-MAC are these defined somewhere else? References would be nice
>  here.

P-MAC does not occur in the draft; I think you mean B-MAC. C-MAC is
Customer/Client MAC address and B-MAC is Backbone MAC address as
further specified in RFC 7623. These can be spelled out and a
reference to RFC 7623 (which is already listed in the References for
the draft) added.

>  * Section 1.3,  Section 2.1 and Section 2.2 describes P nodes in different
>  ways and that has created confusion to me. Can this be well defined in the
>  terminology section once and just be used in other place?

OK, except I think it should be spelled out on first use in 2.1. But
certainly the wording should be parallel in these cases.

>  * Section 2.5 : "[802.3]" is this supposed to be a reference? it leads to
>  nowhere.

Yes, it is intended to be reference to IEEE Std 802.3-2015 (or
whatever the most recent version is). I have no idea why the nits
checker doesn't complain about this being missing from the References
sections. If it did, it would already have been fixed. Since this is
just an example, I think it can be added as an Informational
Reference.

>  * Section 3.1.1.2.1 : first time encountered "network management station
>  (NMS)", if this document is not introducing it then I would suggest to at 
> this
>  to section 1.3 and add some descriptive texts, otherwise define it.

Would it be sufficient to add an entry in the terminology section
(1.3) and a reference to RFC 6623?

>  * Section 3.1.2.1 : would be nice to expand MTU.

Sure.

>  * Section 3.2.1: I  can't really parse - "EVPN Network OAM SHOULD provide
>  mechanisms for measuring packet loss for a given service [RFC7680] 
> [RFC6673]."
>  are these IPPM mechanisms recommended to be used for EVPN networks? or are
>  those merely examples?

These are examples.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-07: (with COMMENT)

[Donald Eastlake]

Hi Erik,

On Mon, Apr 5, 2021 at 3:31 PM Erik Kline via Datatracker
 wrote:
>
> Erik Kline has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-07: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> [ section 2.4 ]
>
> * Up to you if you want to include ICMPv6 [RFC4443] in the list of
>   applicable mechanism.

That seems like a good idea to me. I tend to think of "ICMP" as
covering both v4 and v6 but the only RFC reference, which was probably
added later, is for v4. I'll add v6.

>   =)
>
> [ section 3.1.1.2+ ]
>
> * I can't tell what the mandatory to implement behaviour is.  3.1.1.2 says
>   that implementations MUST support event-driven defect indication which
>   can be categorized into two types.
>
>   Both types say they SHOULD be supported.  If the overall behaviour is
>   a MUST, shouldn't one of these be MTI?  Or is that not important and the
>   point is that any implementation MUST choose at least one to support?

This seems like a good point. To minimize change at this point, I can
re-word to make it clear that at least one of the two types of
event-driven defect indication MUST be implemented, which I believe is
already implied.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Martin Duke's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-06: (with COMMENT)

[Donald Eastlake]

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
 d3e...@gmail.com

On Sat, Mar 27, 2021 at 3:54 PM Martin Duke  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  wrote:
>>
>> Hi Martin,
>>
>> On Fri, Mar 26, 2021 at 12:23 PM Martin Duke via Datatracker
>>  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,
>> > dela

Re: [bess] Martin Duke's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-06: (with COMMENT)

[Donald Eastlake]

Hi Martin,

On Fri, Mar 26, 2021 at 12:23 PM Martin Duke via Datatracker
 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
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-06.txt

[Donald Eastlake]

This is a very minor update fixing a few things pointed out by Martin
in his AD review.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Fri, Mar 19, 2021 at 12:45 PM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : EVPN Operations, Administration and Maintenance 
> Requirements and Framework
> Authors : Samer Salam
>   Ali Sajassi
>   Sam Aldrin
>   John E. Drake
>   Donald E. Eastlake
> Filename: draft-ietf-bess-evpn-oam-req-frmwk-06.txt
> Pages   : 20
> Date: 2021-03-19
>
> Abstract:
>This document specifies the requirements and reference framework for
>Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
>The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider
>Backbone Bridge EVPN).  The framework defines the layered OAM model
>encompassing the EVPN service layer, network layer, underlying Packet
>Switched Network (PSN) transport layer, and link layer but focuses on
>the service and network layers.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-06
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-06
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-05.txt

[Donald Eastlake]

This revision includes responses to the Last Call comments and minor
editorial improvements.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Wed, Feb 17, 2021 at 3:43 PM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : EVPN Operations, Administration and Maintenance 
> Requirements and Framework
> Authors : Samer Salam
>   Ali Sajassi
>   Sam Aldrin
>   John E. Drake
>   Donald E. Eastlake
> Filename: draft-ietf-bess-evpn-oam-req-frmwk-05.txt
> Pages   : 20
> Date: 2021-02-17
>
> Abstract:
>This document specifies the requirements and reference framework for
>Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
>The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider
>Backbone Bridge EVPN).  The framework defines the layered OAM model
>encompassing the EVPN service layer, network layer, underlying Packet
>Switched Network (PSN) transport layer, and link layer but focuses on
>the service and network layers.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-05
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-05
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Secdir last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

[Donald Eastlake]

Hi Melinda

On Tue, Feb 16, 2021 at 12:19 AM Melinda Shore via Datatracker
 wrote:
> Reviewer: Melinda Shore
> Review result: Has Nits
>
> This is a very nicely-structured, efficient, well-written document - among the
> most clearly-written that I've read in a few years.

Thanks.

> Nits:  As a minor point, I am really not a fan of using RFC 2119 language for
> informational documents, and in this case it's being used somewhat
> inconsistently (for example, the lowercase "must" in section 4).

I agree that usage should be consistent. I'll capitalize that "must".

As to the general question of using RFC 2119 language in this
document, I guess we will see what the IESG says.

> I'm also a
> bit unclear on what's intended by "must optionally authenticate" and suggest
> that that should be clarified as to whether what's meant is "mandatory to
> implement but optional to use," or "optional to implement" and should probably
> be a "SHOULD" (or a "should").

Of the three points listed in the Security Considerations, I would
agree that the first two should be SHOULD. But the third, preventing
OAM packet leaking, is, I believe, correctly a MUST.

"Optionally authenticate communicating endpoints" refers, in opinion,
to an implementation requirement, not a use requirement.

> Additionally, it may be helpful to provide an
> example or two of how the EVPN OAM channel could be exploited as a DOS vector,
> and to explain what problem is solved by authenticating EVPN endpoints.

One example would be forged communications that overflow the
capability of an OAM endpoint to maintain state.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Tsvart last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

[Donald Eastlake]

Hi David,

On Tue, Feb 16, 2021 at 10:46 AM David Black via Datatracker
 wrote:
> Reviewer: David Black
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-...@ietf.org if you reply to or forward this review.
>
> I did not notice any transport-related issues, but found a few editorial nits
> that could use some attention:
>
> The draft covers only the F (fault) and P (performance) aspects of the
> FCAPS set of management/maintenance domains.  It might be useful to
> say something about where to look for requirements-related information
> on the other three.

For Configuration and Security (beyond the Security Considerations
section of the document), perhaps this document should refer readers
to the standards for the detailed OAM protocol in use. On Accounting,
I think it is pretty much out of scope for this document.

> Please double-check whether the IEEE 802.1Q reference is up to date.

This won't be published as an RFC for months. I think whether the IEEE
802.1Q reference is completely up to date and in the format preferred
by the IEEE is an excellent thing for the RFC Editor to check as they
normally do.  I will update the year from 2014 to 2018.

> Please explain what P nodes are in Figures 1 and 2.

OK.

> Figures 1 and 2 include four OAM layers, of which this draft is only
> concerned with two, Service OAM and Network OAM.  Section 2.1
> should indicate that these two layers are the focus of the draft.

OK.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RtgDir review: draft-ietf-bess-evpn-oam-req-frmwk-04.txt

[Donald Eastlake]

Hi Stig,

See below at .

On Mon, Feb 15, 2021 at 12:27 PM Stig Venaas  wrote:
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> Document: draft-ietf-bess-evpn-oam-req-frmwk-04.txt
> Reviewer: Stig Venaas
> Review Date: 2021-02-15
> IETF LC End Date: 2021-02-16
> Intended Status: Informational
>
> Summary:
>
> This document is basically ready for publication, but has nits that
> should be considered prior to publication.
>
> Comments:
>
> This is the best written draft I've read in a long time. Thanks for
> that! I could not find any issues, except one very minor nit.

Thanks!

> Nits:
>
> As mentioned in some other reviews, it might be good to add the term P
> to the terminology section.

Yeah, that change is in the working copy, will be uploaded soon.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> Regards,
> Stig

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Genart last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

[Donald Eastlake]

Hi Dave,

Thanks for the review. See below.

On Fri, Feb 5, 2021 at 4:44 PM David Schinazi via Datatracker
 wrote:
> Reviewer: David Schinazi
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-bess-evpn-oam-req-frmwk-04
> Reviewer: David Schinazi
> Review Date: 2021-02-05
> IETF LC End Date: 2021-02-16
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Thank you for a well-written document.
>   It introduces a lot of terminology I wasn't used to,
>   but does a good job of explaining it.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>   - The abstract defines all the acronyms (which is great) except PBB, could 
> it define that one too?
>   - Section 2.1 doesn't really explain what a "P node" is.

Sure, we can expand PBB (Provider Backbone Bridge) in the abstract and
say in Section 2.1 that P is Provider. These should probably also be
added to the terminology section. I've made these changes in the
working copy but they are pretty minor so I think I'll wait for the
results of other reviews before uploading a new version.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Document shepherd review of draft-ietf-bess-evpn-oam-req-frmwk-03

[Donald Eastlake]

Hi Matthew,

On Tue, Jul 7, 2020 at 6:52 AM Bocci, Matthew (Nokia - GB)
 wrote:

> Authors
>
> I am the document shepherd for this draft. I have reviewed the draft
> and have the following comments. In general, the draft is clear and
> well written – thank you!. Please treat these comments as you would
> any other working group last call comment.
>
> Best regards
> Matthew
>
>
> Section 2.3 EVPN Network OAM
>
> […]
>
>  - the MP2P tunnels used for the transport of unicast traffic between
>PEs. EVPN allows for three different models of unicast label
>assignment: label per EVI, label per  and label
>per MAC address. In all three models, the label is bound to an EVPN
>Unicast FEC.
>
>  EVPN Network OAM MUST provide mechanisms to check the operation of
>  the data plane and verify that operation against the control plane
>  view.
>
> MB> The formatting here breaks the list up and makes it a bit hard
> to parse. Maybe you intend this paragraph to be attached to the list
> bullet above? If so then it would be clearer to merge the paragraphs
> or indent it to be aligned with the list bullet text.

I believe that paragraph should be attached to the list bullet above by
appending it to the bullet paragraph. (See, for example, the end of
the immediately following bullet paragraph.)

>
>
> EVPN network OAM mechanisms MUST provide in-band management
>capabilities. As such, OAM messages MUST be encoded so that they
>exhibit identical entropy characteristics to data traffic.
>
> MB> I think it would be clearer to refer to in-band monitoring
> rather than management to prevent confusion with the DCN of
> RFC5718. It is the monitoring that is in-band. I would also suggest
> adding a clarification with the second sentence in this paragraph
> along the lines of “… in order that they share the same fate.”

OK. That would change this paragraph to read

   EVPN network OAM mechanisms MUST provide in-band monitoring
   capabilities. As such, OAM messages MUST be encoded so that they
   exhibit identical entropy characteristics to data traffic in order
   that they share the same fate.

One additional change: In line with the first change above, I believe
that the following paragraph should be merged with the preceding
bullet item:

   EVPN Network OAM MUST provide mechanisms to check the operation of
   the data plane and verify that operation against the control plane
   view for the DF filtering function.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-03.txt

[Donald Eastlake]

This revision includes the resolution of comments by Xiao Min as
discussed on this mailing list.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Fri, Jul 3, 2020 at 10:38 AM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : EVPN Operations, Administration and Maintenance 
> Requirements and Framework
> Authors : Samer Salam
>   Ali Sajassi
>   Sam Aldrin
>   John E. Drake
>   Donald E. Eastlake
> Filename: draft-ietf-bess-evpn-oam-req-frmwk-03.txt
> Pages   : 19
> Date: 2020-07-03
>
> Abstract:
>This document specifies the requirements and reference framework for
>Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
>The requirements cover the OAM aspects of EVPN and PBB-EVPN.  The
>framework defines the layered OAM model encompassing the EVPN service
>layer, network layer and underlying Packet Switched Network (PSN)
>transport layer.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-03
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-dunbar-bess-bgp-sdwan-usage-07

[Donald Eastlake]

I support WG adoption of this draft.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Tue, Jun 23, 2020 at 8:13 AM  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dunbar-bess-bgp-sdwan-usage-07 [1] ..
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on 7th July 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and IPR Poll fordraft-ietf-bess-evpn-oam-req-frmwk-02

[Donald Eastlake]

Hi,

On Sat, Jun 20, 2020 at 5:12 AM  wrote:
> Hi Matthew, Stephane and Authors,
>
> After reading through this draft, I think it's very useful and
> well-written, so I support its publication.

Thanks for your support and comments.

> I also have several specific comments as follows.
>
> In section 2.2, it says
>
> "
> The EVPN PE SHOULD support MEP
>  functions in the applicable service OAM protocol. This includes both
>  Up and Down MEP functions.
> "
>
> In my opinion it's reasonable to include Down MEP functions, which
> means sending OAM messages between EVPN PE and CE, but UP MEP
> functions should be excluded, because that means sending OAM
> messages between EVPN PEs, which I think doesn't belong to EVPN
> Service OAM. My understanding is that for any kind of EVPN Service
> OAM it must include CE, if an OAM mechanism runs between EVPN PEs,
> then this OAM mechanism belongs to EVPN Network OAM or EVPN
> Transport OAM.

Replying just for myself, I believe MEPs are logically in ports. What
we are talking about here is the MEP logically located in the
CE-facing port of the PE. Certainly down MEP functions from there go
to the CE. I think UP MEP functions would go to the UP MEP logically
located in the CE facing port of a remote PE. So, this is PE-to-PE and
similar to EVPN Network OAM, which runs from the brain of one PE to
the brain of another, but not identical. So I do not see any reason
why both should not be available.  Perhaps these distinctions should
be clarified in the text.

> In section 2.2, it says
>
> "
> The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP
>  Advertisement route. Since these are not subject to mobility, they
>  SHOULD be advertised with the static (sticky) bit set (see Section
>  15.2 of [RFC7432]).
> "
>
> In my opinion "MEP/MIP" should be substituted by "MIP", because as I
> said above, the MEP at the EVPN PE should be a Down MEP, it's peer
> MEP is at locally attached CE, there is no need to advertise it to
> remote PEs.

See my response above. By the way, I think if there is a MIP at PE1
then an UP MEP at a remote PE can run through the MIP to a CE local to
PE1 (actually, to be precise, to the PE facing port of that CE).

> In section 3.1.2.2, it says
>
> "EVPN Service OAM mechanisms only have visibility to the PEs but not
>  the MPLS/IP P nodes. As such, they can be used to deduce whether the
>  fault is in the customer's own network, the local CE-PE segment or
>  remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms
>  can be used for fault isolation between the PEs and P nodes."
>
> Considering in section 2.3 the first sentence reads "EVPN Network
> OAM is visible to the PE nodes only", I suggest to rephrase this
> paragraph possibly as below:
>
> "EVPN Service OAM and EVPN Network OAM mechanisms only have
> visibility to the PEs but not the MPLS/IP P nodes. As such, they can
> be used to deduce whether the fault is in the customer's own
> network, the local CE-PE segment, the PE-PE segment or the remote
> CE-PE segment(s). EVPN Transport OAM mechanisms can be used for
> fault isolation between the PEs and P nodes."

Your suggested change looks OK to me.

> Section 3.1.2.1, there is a typo, s/to rest a representative path
> between PEs/to test a representative path between PEs.

OK, we'll fix that.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> Best Regards,
>
> Xiao Min
>
> 原始邮件
> 发件人：Bocci,Matthew(Nokia-GB) 
> 收件人：draft-ietf-bess-evpn-oam-req-fr...@ietf.org 
> ;bess@ietf.org ;
> 日 期 ：2020年06月15日 18:56
> 主 题 ：[bess] WG Last Call and IPR Poll fordraft-ietf-bess-evpn-oam-req-frmwk-02
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> This email starts a two-week working group last call 
> fordraft-ietf-bess-evpn-oam-req-frmwk-02
>
>
>
> Please review the draft and send any comments to the BESS list. Also, please 
> indicate if you support publishing the draft as a standards track RFC.
>
>
>
> This poll runs until Monday 29th June 2020.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to this 
> Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
> rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this document please 
> respond to this email and indicate whether or not you are aware of any 
> relevant undisclosed IPR. The Document won't progress without answers from 
> all the Authors and Contributors.
>
> There is currently no IPR disclosed.
>
> Thank you,
>
> Matthew & Stephane

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02

[Donald Eastlake]

I support this draft as an author.

I am not aware of any undisclosed IPR in this draft.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Mon, Jun 15, 2020 at 6:55 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> This email starts a two-week working group last call for
> draft-ietf-bess-evpn-oam-req-frmwk-02
>
>
>
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as a standards track
> RFC.
>
>
>
> This poll runs until Monday 29th June 2020.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
> There is currently no IPR disclosed.
>
> Thank you,
>
> Matthew & Stephane
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-gmsm-bess-evpn-bfd-04

[Donald Eastlake]

Hi,

On Thu, Apr 30, 2020 at 11:33 AM Bocci, Matthew (Nokia - GB)
 wrote:
>
> Folks
>
> This email closes this adoption call. Apologies for the delay.
>
> I believe there is consensus to adopt it.
>
> Authors: Please submit a new version as WG document.

Thanks, we will post a -00 WG version without other changes and then
work on incorporating changes from the comments made mostly at the
Singapore meeting.

Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> Best regards
>
>
>
> Matthew
>
>
>
> From: "Bocci, Matthew (Nokia - GB)" 
> Date: Wednesday, 26 February 2020 at 14:42
> To: "draft-gmsm-bess-evpn-...@ietf.org" , 
> "bess@ietf.org" 
> Cc: "bess-cha...@ietf.org" 
> Subject: WG adoption poll for draft-gmsm-bess-evpn-bfd-04
> Resent from: 
> Resent to: Stephane Litkowski , 
> , 
> Resent date: Wednesday, 26 February 2020 at 14:42
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for 
> draft-gmsm-bess-evpn-bfd-04 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to this 
> Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
> rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please 
> respond to this email and indicate whether or not you are aware of any 
> relevant undisclosed IPR, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please explicitly 
> respond only if you are aware of any IPR that has not yet been disclosed in 
> conformance with IETF rules.
>
>
>
> This poll for adoption closes on Wednesday 11th March 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/
>
>
>
>
>
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-gmsm-bess-evpn-bfd-04

[Donald Eastlake]

I am not aware on any undisclosed IPR in this draft.

I support WG adoption of this draft as a co-author.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Wed, Feb 26, 2020 at 9:42 AM Bocci, Matthew (Nokia - GB)
 wrote:
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for 
> draft-gmsm-bess-evpn-bfd-04 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to this 
> Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
> rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please 
> respond to this email and indicate whether or not you are aware of any 
> relevant undisclosed IPR, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please explicitly 
> respond only if you are aware of any IPR that has not yet been disclosed in 
> conformance with IETF rules.
>
>
>
> This poll for adoption closes on Wednesday 11th March 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/
>
>
>
>
>
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] EVPN Operations, Administration and Maintenance Requirements and Framework

[Donald Eastlake]

Hi,

This is reminder that draft
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/ exists.
Please take a look. Comments or suggestions appreciated.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-02.txt

[Donald Eastlake]

Hi,

This revision has only trivial editorial improvements and one minor
author info change. I believe the draft continues to be read for WG
Last Call.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Wed, Jan 1, 2020 at 7:09 PM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : EVPN Operations, Administration and Maintenance 
> Requirements and Framework
> Authors : Samer Salam
>   Ali Sajassi
>   Sam Aldrin
>   John E. Drake
>   Donald E. Eastlake
> Filename: draft-ietf-bess-evpn-oam-req-frmwk-02.txt
> Pages   : 19
> Date: 2020-01-01
>
> Abstract:
>This document specifies the requirements and reference framework for
>Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
>The requirements cover the OAM aspects of EVPN and PBB-EVPN.  The
>framework defines the layered OAM model encompassing the EVPN service
>layer, network layer and underlying Packet Switched Network (PSN)
>transport layer.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-02
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-02
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-01.txt

[Donald Eastlake]

This draft has been revised to correctly show my affiliation. No other
changes made.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

On Mon, Jul 8, 2019 at 3:05 PM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : EVPN Operations, Administration and Maintenance 
> Requirements and Framework
> Authors : Samer Salam
>   Ali Sajassi
>   Sam Aldrin
>   John E. Drake
>   Donald E. Eastlake
> Filename: draft-ietf-bess-evpn-oam-req-frmwk-01.txt
> Pages   : 19
> Date: 2019-07-08
>
> Abstract:
>This document specifies the requirements and reference framework for
>Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
>The requirements cover the OAM aspects of EVPN and PBB-EVPN.  The
>framework defines the layered OAM model encompassing the EVPN service
>layer, network layer and underlying Packet Switched Network (PSN)
>transport layer.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-01
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] revision of draft-gmsm-bess-evpn-bfd

[Donald Eastlake]

Hi,

draft-gmsm-bess-evpn-bfd-02 has been posted.
https://tools.ietf.org/html/draft-gmsm-bess-evpn-bfd-02

Significant changes from the previous version include the following:

VXLAN encapsulation is covered as well as MPLS.
As requested by the WG, BFD discriminator distribution uses BFD rather than
LSP ping.
More information on P2MP tunnels and more details on encapsulation.


Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-salam-bess-evpn-oam-req-frmwk-01

[Donald Eastlake]

As an author, I support adoption of this work.

I am not aware of any undeclared IPR in this work.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

On Wed, Feb 6, 2019 at 5:23 AM Bocci, Matthew (Nokia - GB)
 wrote:
>
> This email begins a two-week poll for adoption of 
> draft-salam-bess-evpn-oam-req-frmwk-01.txt
>
>
>
> Please review the draft and post any comments to the BESS working group list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to this 
> Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
> rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please 
> respond to this email and indicate whether or not you are aware of any 
> relevant undisclosed IPR, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please explicitly 
> respond only if you are aware of any IPR that has not yet been disclosed in 
> conformance with IETF rules.
>
>
>
> This poll for adoption closes on Wednesday 20th February 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Request to adopt draft-salam-bess-evpn-oam-req-frmwk

[Donald Eastlake]

Hi,

There was good support for this EVPN OAM Requirements and Framework draft
at the BESS WG meeting in Bangkok. I request that a call for WG adoption be
started. The draft is here:
https://tools.ietf.org/html/draft-salam-bess-evpn-oam-req-frmwk-01

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Donald Eastlake]

Hi Jorge,

On Mon, Nov 5, 2018 at 9:12 PM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Hi Donald,
>
> Thank you for this.
> For the second question, I get from your answer that you will keep both 
> encapsulations for the time being?

Well, once a draft is posted, it can't be changed, so the currently
posted -01 won't change but the -02 version that is being worked on
and is not yet posted eliminates the alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thanks.
> Jorge
>
>
> -----Original Message-
> From: Donald Eastlake 
> Date: Monday, November 5, 2018 at 8:48 PM
> To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
> Cc: "bess@ietf.org" , 
> "draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 
> 
> Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01
>
> Hi Jorge,
>
> On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
> View)  wrote:
> >
> > Dear authors,
> >
> > I couldn’t make it to the BESS meeting, so my apologies if some of 
> these things have been discussed.
> >
> > Some comments/questions:
>
> Thanks for sending comments.
>
> > - In the last IETF, I suggested the use of BGP and the BGP-BFD 
> attribute to exchange discriminators, as in section 3.1.6 of 
> draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
> not in the new version. This would allow the signaling of the discriminators 
> along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
> etc. without the burden of having to support the EVPN LSP-ping draft.
>
> There is a draft version -02 in the works intended to include
> distribution of BFD discriminators in BGP but this revision was not
> completed to the agreement of the authors in time to posted before
> this meeting.
>
> > - The draft describes an encapsulation and an alternative 
> encapsulation. Is the intend to keep both? Wouldn't be better to leave only 
> one to ease implementations and interoperability?
>
> Currently, the candidate version -02 draft dispenses with with the
> alternative encapsulation.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA
>  d3e...@gmail.com
>
> > Thank you.
> > Jorge
>
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Donald Eastlake]

Hi Jorge,

On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Dear authors,
>
> I couldn’t make it to the BESS meeting, so my apologies if some of these 
> things have been discussed.
>
> Some comments/questions:

Thanks for sending comments.

> - In the last IETF, I suggested the use of BGP and the BGP-BFD attribute to 
> exchange discriminators, as in section 3.1.6 of 
> draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
> not in the new version. This would allow the signaling of the discriminators 
> along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
> etc. without the burden of having to support the EVPN LSP-ping draft.

There is a draft version -02 in the works intended to include
distribution of BFD discriminators in BGP but this revision was not
completed to the agreement of the authors in time to posted before
this meeting.

> - The draft describes an encapsulation and an alternative encapsulation. Is 
> the intend to keep both? Wouldn't be better to leave only one to ease 
> implementations and interoperability?

Currently, the candidate version -02 draft dispenses with with the
alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thank you.
> Jorge

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Revision of draft-salam-bess-evpn-oam-req-frmwk posted

[Donald Eastlake]

Hi,

Revised draft draft-salam-bess-evpn-oam-req-frmwk-01.txt has been posted to
resolve the comments in the thread on the BESS WG mailing list with subject
"EVPN FECs in LSP Ping". At the BESS WG meeting in Bangkok, I plan to ask
that this draft become a WG draft. Please take a look.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] EVPN FECs in LSP Ping

[Donald Eastlake]

Hi Sasha,

On Fri, Sep 21, 2018 at 1:02 PM Alexander Vainshtein
 wrote:
>
> Donald,
> Lots of thanks for your response.
>
> I would like to clarify my question regarding learning of the MAC address of 
> the customer MEP.
>
> I fully agree that this address will be locally learned by the PE to whic the 
> relevant customer site is attached.
>
> But will this address advertised to remote PEs?
>
> My reading of 7432 is that in most cases PEs advertise MAC addresses that 
> have been locally learned from some CP protocol; 7432 specifically mentions 
> ARP/NDP and DHCP/DHCPv6.
>
> I think that in order to learn and advertise MAC addresses of customer MEPs, 
> the PE should trap or snoop Ethernet Service OAM frames (trap is required for 
> LTM frames if MIP us intanciated in the PE).
>
> Does this make sense to you?

I would agree that a PE has to advertise the MAC addresses it learns
from the local reception Ethernet Service OAM frames if it wants to
support that service and it would be reasonable to mention this in the
EVPN OAM framework document. RFC 7432 was not considering OAM.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Regards
>
> Thumb typed by Sasha Vainshtein
>
> From: Donald Eastlake
> Sent: Monday, September 17, 01:43
> Subject: Re: EVPN FECs in LSP Ping
> To: Alexander Vainshtein
> Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, Michael 
> Gorokhovsky, Ron Sdayoor, Rotem Cohen
>
> Hi Sasha, Thanks for your questions. See below. On Thu, Sep 6, 2018 at 9:58 
> AM Alexander Vainshtein wrote: > > Dear authors of the EVPN OAM requirements 
> and Framework draft, > > I have looked up the draft, and it looks to me as a 
> good starting > point for work on EVPN OAM. Thanks. > I would like to clarify 
> two points with regard to the draft: > > 1. In order to pass unicast EAOM 
> frames (LBM/LBR and LTR), the > local MAC-VRF must learn the MAC address of 
> the customer MEP and > advertise it to remote PEs as a MAC/IP Advertisement 
> route. Should > this be considered as a special case of learning from the 
> control > plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC 
> > 7432)? Yes, the MAC address of the customer MEP needs to be learned but 
> Section 9.1 of RFC 7432 includes the following text, which seems adequate to 
> me: The PEs in a particular EVPN instance MUST support local data-plane 
> learning using standard IEEE Ethernet learning procedures. > 2. The draft 
> seems to prop
 ose extension of LSP Ping to test/verify > connectivity to the FECs advertised 
as NRLI of EVPN routes. I have > checked the IANA Registry, and no values for 
these FECs have been > allocated yet. Do you plan any specific work on this? 
LSP Ping is one mechanism indirectly referenced in Section 2.4 of the draft via 
the reference to RFC 6425 but there are others. Since OAM messages need to 
follow the same path as data, as far as practical, it seem to me there should 
not be any FECs allocated for OAM beyond those already needed for data. 
Probably wording in the draft related to FECs should be checked/adjusted. 
Thanks, Donald === Donald E. Eastlake 3rd 
+1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA 
d3e...@gmail.com > Regards, > Sasha > > Office: +972-39266302 > Cell: 
+972-549266302 > Email: alexander.vainsht...@ecitele.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] EVPN FECs in LSP Ping

[Donald Eastlake]

Hi Sasha,

Thanks for your questions. See below.

On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein
 wrote:
>
> Dear authors of the EVPN OAM requirements and Framework draft,
>
> I have looked up the draft, and it looks to me as a good starting
> point for work on EVPN OAM.

Thanks.

> I would like to clarify two points with regard to the draft:
>
> 1.  In order to pass unicast EAOM frames (LBM/LBR and LTR), the
> local MAC-VRF must learn the MAC address of the customer MEP and
> advertise it to remote PEs as a MAC/IP Advertisement route. Should
> this be considered as a special case of learning from the control
> plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC
> 7432)?

Yes, the MAC address of the customer MEP needs to be learned but
Section 9.1 of RFC 7432 includes the following text, which seems
adequate to me:

   The PEs in a particular EVPN instance MUST support local data-plane
   learning using standard IEEE Ethernet learning procedures.

> 2. The draft seems to propose extension of LSP Ping to test/verify
> connectivity to the FECs advertised as NRLI of EVPN routes. I have
> checked the IANA Registry, and no values for these FECs have been
> allocated yet.  Do you plan any specific work on this?

LSP Ping is one mechanism indirectly referenced in Section 2.4 of the
draft via the reference to RFC 6425 but there are others.

Since OAM messages need to follow the same path as data, as far as
practical, it seem to me there should not be any FECs allocated for
OAM beyond those already needed for data. Probably wording in the
draft related to FECs should be checked/adjusted.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com


> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:   +972-549266302
> Email:  alexander.vainsht...@ecitele.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slot requests for BESS WG session - IETF 102 - Montreal

[Donald Eastlake]

Hi,

I request 10 minutes to present and answer questions about
"EVPN Operations, Administration and Maintenance Requirements and
Framework" (draft-salam-bess-evpn-oam-req-frmwk) and
"Fault Management for EVPN Networks" draft-gmsm-bess-evpn-bfd.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Tue, Jun 12, 2018 at 6:13 AM,  wrote:

> All,
>
>
>
> It is time we start building the BESS WG agenda for Montreal.
>
>
>
> Please send us your request for a presentation slot, indicating draft
> name, speaker, and desired duration (covering presentation and discussion).
> If it is not the first presentation of the draft, please give a reason why
> it is required to have a new presentation slot.
>
>
>
>
>
> Thank you
>
>
>
> Stephane & Matthew
>
>
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess