Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Stephane,

Please see in-line with [jorge2].
Thank you!
Jorge

From: slitkows.i...@gmail.com 
Date: Monday, August 31, 2020 at 11:49 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) , 
draft-ietf-bess-evpn-pref...@ietf.org , 
bess-cha...@ietf.org , bess@ietf.org 
Subject: RE: Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Jorge,

Please find additional feedback inline.
(Stripping things we agree on)

Stephane


From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: vendredi 19 juin 2020 20:37
To: slitkows.i...@gmail.com; draft-ietf-bess-evpn-pref...@ietf.org; 
bess-cha...@ietf.org; bess@ietf.org
Subject: Re: Shepherd's Review of draft-ietf-bess-evpn-pref-df

Hi Stephane,

Thanks for the review and my apologies for the delay.
We just posted a new revision.

As usual, very good points. Please see in-line.

Thx
Jorge

From: "slitkows.i...@gmail.com" 
mailto:slitkows.i...@gmail.com>>
Date: Wednesday, February 26, 2020 at 3:20 PM
To: 
"draft-ietf-bess-evpn-pref...@ietf.org"
 
mailto:draft-ietf-bess-evpn-pref...@ietf.org>>,
 'BESS' mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: Shepherd's Review of draft-ietf-bess-evpn-pref-df
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:jorge.raba...@nokia.com>>, 
mailto:senthil.sathap...@nokia.com>>, 
mailto:p...@juniper.net>>, 
mailto:w...@juniper.net>>, 
mailto:jdr...@juniper.net>>, 
mailto:saja...@cisco.com>>, 
mailto:satya...@cisco.com>>
Resent-Date: Wednesday, February 26, 2020 at 3:20 PM



Section 4.1:

“ Note that, by default, the Highest-Preference is chosen for each
   ES or vES, however the ES configuration can be changed to the
   Lowest-Preference algorithm as long as this option is consistent
   in all the PEs in the ES.
I don’t think it is a good idea to open this modification. People can play with 
preference values to achieve the required behavior while always keeping high 
pref.
We have no way to ensure consistency, except if we advertise the behavior as 
part of the exct. Consistency of DF election is key and needs to be ensured as 
much as we can.
[Jorge] the idea is have the highest preference as default (maybe use normative 
language?), which means that it will work fine. Opening to lowest is to give 
more flexibility, knowing that if the user has to change the config from the 
default, they will do it in all the PEs of the ES.

[SLI] I don’t think this is a good idea, consistency is really important, if 
you absolutely want to do both lowest and highest, you can allocate a new DF 
Alg for lowest so we ensure that everybody uses the same algorithm. But I don’t 
think this is necessary, having highest preference is enough. I don’t remember 
any feature using a preference that can do both highest and lowest, it is 
usually one or the other.


[Jorge2] ok, we can leave just the highest-preference in section 4.1. We’ll fix 
it in the next revision. Note that in 4.2 we still need to have highest and 
lowest pref per ethernet tag range to make sure there is load balancing.








“When PE3's vES2 comes back up, PE3 will start a boot-timer (if

   booting up) or hold-timer (if the port or EVC recovers).  That

   timer will allow some time for PE3 to receive the ES routes from

   PE1 and PE2. »



Are you changing the way the DF election works ? Usually, PE advertises its 
route and then wait to receive other routes.

[Jorge] those timers are on top of the FSM defined in RFC8584, e.g. we need to 
give some extra time before the ES goes up and we advertise the ES route, if 
the ES is configured with the DP capability. This is because the advertised 
preference and DP values may not be the same as the configured ones, and the 
‘in-use’ values will depend on the other ES routes in the ES. If we advertise 
the ES route immediately after the ES is up, we may not have received the other 
ES routes and we don’t know what “in-use” values to advertise in order to avoid 
preemption in the ES. I added some text on point 5 (section 4.3).





[SLI] As we are updating the FSM, could we have new state and events defined to 
update the FSM similarly as we have in RFC8584 ?
[jorge2] not sure if we should update the FSM, the reason being that those hold 
timers are generic for any redundancy mechanism, to avoid attracting traffic 
from the access before the core IGP/BGP are up and have all the required routes 
available. Some implementations use fixed timers, others configurable timers, 
others watch when the IGP/BGP come up and leave an additional delta. I thought 
the current text is generic enough to allow all those implementations.





What happens if all PEs on the ES are failing at the same time or the ES 
booting up on all the PEs at the same time ? you have no way to hear what is 
the pref from the remote.

[Jorge] The non-revertive capability makes sense when 

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Eric,

Thanks for your review and your comments, please refer to my replies inline 
marked with [AS].

On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker"  wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I would appreciate 
a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

PS: as a side note, I found that this document uses too many acronyms even 
for
short words (e.g., "SN" instead of "Subnet"). There are also very long
sentences that, when combined with acronyms, make reading difficult.

== COMMENTS ==

-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route inter-subnet 
IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 only, then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded (and 
vice-versa).

[AS] the above quoted text is provided as an example and it should be clear 
enough
Without making the sentence to verbose. 

-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be the one used 
in
the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." by 
"then
the IRB interface MAC address MUST be the one used in the initial ARP reply 
or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS"
because routers MAC addresses are also advertised by Router Advertisements.

[AS] I don't think the IRB interface MAC address in the initial ARP reply can 
be used 
In RA because it is a multicast packet - i.e., the MAC address of old IRB 
interface and the
New IRB interface cannot be sent in a single multicast packet.

-- Section 5.1 --
Should also mention NDP when writing "(via an ARP request)" in the first
paragraph.

[AS] Done.

In the same vein, please add "NDP cache" to "Furthermore, it adds this TS's 
MAC
and IP address association to its ARP table".

[AS] Done.

As I am not an expert in EVPN, I am puzzled by the math about the Length 
field
"either 40 (if IPv4 address is carried) or 52 (if IPv6 address is carried)."

[AS] for IPv6, the NLRI has 12 additional bytes.

-- Section 5.2 --
This section also only mentions IPv4 ARP table, please add IPv6 NDP cache.

[AS] Done.

-- Section 6.1 --
Same comments as for section 5.1

AS] Done.

-- Section 6.2 --
Same comments as for section 5.2

[AS] Done.

-- Section 7 --
Good to state "Although the language used in this section is for IPv4 ARP, 
it
equally applies to IPv6 ND."; even if I would have preferred to use by 
default
IPv6 ND ;-)

[AS] yes, the quoted sentence already exist. 

Please note that in IPv6 there are often at least TWO IPv6 addresses per MAC
(one link-local fe80::... and one global); so, "In the following 
subsections,
it is assumed that the MAC and IP addresses of a TS have one-to-one
relationship (i.e., there is one IP address per MAC address and vice 
versa). "
is obviously never the case for IPv6. I understand that the rest of the
paragraph explains how to handle the case but it could be easier to treat 
IPv6
in a separate sentence.

-- Section 7.1 --
While about mobility, this section appears to be also applicable to 
Duplicate
Address Detection but is unclear on what to do when the same IP but 
different
MAC (i.e., an actual IP address collision). Or is it covered in other 
documents?

[AS] duplicate MACs are covered in RFC 7432.

== NITS ==

-- Section 1 --
"BD and subnet are equivalent terms" while in the rest of the document "IP
subnet" is often used. If "subnet IP" and "subnet" are synonyms, then I 
suggest
to keep using one for consistency or at least mention that "IP subnet" and
"subnet" are the same concept (or explain the difference if they are not
identical).

[AS] Added clarification that "subnet" means "IP subnet".




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

[bess] I-D Action: draft-ietf-bess-evpn-per-mcast-flow-df-election-04.txt

[internet-drafts]

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   : Per multicast flow Designated Forwarder Election for 
EVPN
Authors : Ali Sajassi
  Mankamana Mishra
  Samir Thoria
  Jorge Rabadan
  John Drake
Filename: draft-ietf-bess-evpn-per-mcast-flow-df-election-04.txt
Pages   : 12
Date: 2020-08-31

Abstract:
   [RFC7432] describes mechanism to elect designated forwarder (DF) at
   the granularity of (ESI, EVI) which is per VLAN (or per group of
   VLANs in case of VLAN bundle or VLAN-aware bundle service).  However,
   the current level of granularity of per-VLAN is not adequate for some
   applications.[I-D.ietf-bess-evpn-df-election-framework] improves base
   line DF election by introducing HRW DF election.
   [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN
   to Multicast flows, routes to sync them and a default DF election.
   This document is an extension to HRW base draft
   [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW
   algorithm for the Multicast flows to do DF election at the
   granularity of (ESI, VLAN, Mcast flow).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-per-mcast-flow-df-election/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-per-mcast-flow-df-election-04
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-per-mcast-flow-df-election-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-per-mcast-flow-df-election-04


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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-na-flags-05

[Robert Sparks]

Thanks for considering my suggestions Jorge - your edits address all my 
concerns!


RjS

On 8/31/20 3:46 AM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:


Robert,

Thank you very much for the review. Great points.

Please see in-line with [Jorge]. All the changes will be included in 
the next revision.


Thank you!

Jorge

*From: *Robert Sparks via Datatracker 
*Date: *Tuesday, August 18, 2020 at 6:11 PM
*To: *gen-...@ietf.org 
*Cc: *draft-ietf-bess-evpn-na-flags@ietf.org 
, last-c...@ietf.org 
, bess@ietf.org 

*Subject: *Genart last call review of draft-ietf-bess-evpn-na-flags-05

Reviewer: Robert Sparks
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-na-flags-05
Reviewer: Robert Sparks
Review Date: 2020-08-18
IETF LC End Date: 2020-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC but with nits to
address before publication

The protocol being defined seems fine, and the IANA considerations are 
well
constructed. I have a nagging feeling that there are new security 
concerns this
introduces, but haven't been able to identify anything specific. I 
appreciate

that the document discusses what happens when a bad-actor introduces
intentionally mis-configured flags.

Editorial Issues:

The Abstract is full of acronyms that are not universally understood, 
and it

buries the point of the document. Please consider rewriting to focus more
specifically on the goal of the draft (see the introduction in the 
shepherd's
writeup), keeping in mind that the abstract should make sense to 
people who

don't know yet what PE stands for. Much of what you currently have in the
Abstract can be left to the Introduction. I expect a shorter (two or three
sentence) abstract will suit the document better.

[Jorge] we simplified the abstract as follows, hopefully it addresses 
your comment:


   Ethernet Virtual Private Network (EVPN) uses MAC/IP Advertisement

   routes to advertise locally learned MAC and IP addresses associated

   to host or routers.  The remote Provider Edge (PE) routers may use

   this information to populate their Address Resolution Protocol (ARP)

   or Neighbor Discovery (ND) tables and then reply locally to ARP

   Requests or Neighbor Solicitation messages on behalf of the owner of

   the IP address.  However, the information conveyed in the MAC/IP

   route may not be enough for the remote PE to reply to local ARP or ND

   requests.  This document defines an Extended Community that is

   advertised along with an EVPN MAC/IP Advertisement route and carries

   information relevant to the ARP/ND resolution, so that an EVPN PE

   implementing a proxy-ARP/ND function can reply to ARP Requests or

   Neighbor Solicitations with the correct information.



In section 3.2: The list of three things in the list under "R and O Flags
processing" are all processing steps. But the list of 6 things under 
"I Flag

processing" are not all processing steps. Please change the list to only
include processing steps, and move the examples and commentary to regular
paragraphs after the processing has been specified.

Consider moving the third top-level bullet in 3.2 ("MUST be ignored") 
to be the

first bullet, and after that bullet say "otherwise".

[Jorge] ok, section 3.2 changed as follows:

3.2.  Reception of the EVPN ARP/ND Extended Community
   In addition to the procedures specified in [RFC7432] a PE receiving a
   MAC/IP Advertisement route will process the EVPN ARP/ND Extended
   Community as follows:
   o  The R, O and I Flags MUST be ignored if they are advertised along
  with an EVPN MAC/IP Advertisement route that does not contain an
  IP (IPv4 or IPv6) address.  Otherwise they are processed as
  follows.
   o  R and O Flags processing:
  *  If the EVPN MAC/IP Advertisement route contains an IPv6 address
 and the EVPN ARP/ND Extended Community, the PE MUST add the R
 and O Flags to the ND entry in the ND or proxy-ND table and use
 that information in Neighbor Advertisements when replying to a
 Solicitation for the IPv6 address.
  *  If no EVPN ARP/ND Extended Community is received along with the
 route, the PE will add the default R and O Flags to the entry.
 The default R Flag SHOULD be an administrative choice.  The
 default O Flag SHOULD be 1.
  *  A PE MUST ignore the received R and O Flags for an EVPN MAC/IP
 Advertisement route that contains an IPv4->MAC pair.
   o  I Flag processing:
  *  A PE receiving an EVPN MAC/IP Advertisement route containing an
 IP->MAC and the I Flag set SHOULD 

Re: [bess] Intdir last call review of draft-ietf-bess-evpn-na-flags-05

[Rabadan, Jorge (Nokia - US/Mountain View)]

Thank you for reviewing, Ralf.
We’ll leave the current normative language then. If anyone else has strong 
opinions about it, we can discuss it.

Jorge

From: BESS 
Date: Friday, August 28, 2020 at 6:29 PM
To: int-...@ietf.org 
Cc: last-c...@ietf.org , bess@ietf.org , 
draft-ietf-bess-evpn-na-flags@ietf.org 

Subject: [bess] Intdir last call review of draft-ietf-bess-evpn-na-flags-05
Reviewer: Ralf Weber
Review result: Ready

Moin!

I am an assigned INT directorate reviewer for draft-ietf-bess-evpn-na-flags.

These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/

The draft does a very good job explaining the motivation, definition and use of
the extended community flags with good and applicable examples. I personally
would have used stronger (MUST) language for the R and O bits set to 0 on the
IPv4->MAC transmission (3.1 sub point 2), but as these are optional anyway and
must be ignored by the receiver it really makes no difference.

So long
-Ralf



___
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] Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: (with DISCUSS and COMMENT)

[Murray S. Kucherawy]

Hi,

I saw the change.  However the text of that section still says "new"
twice.  Since the registration was made by RFC 5549, it isn't appropriate
to call it "new".

Any comments on the text I proposed in my DISCUSS?  It's more typical of
"bis" style work, in my experience.

-MSK

On Mon, Aug 31, 2020 at 1:49 AM  wrote:

> Hi Murray,
>
> I have uploaded a new revision that clarifies the IANA section.
>
> -Original Message-
> From: Murray Kucherawy via Datatracker 
> Sent: mercredi 26 août 2020 21:01
> To: The IESG 
> Cc: draft-ietf-bess-rfc5549revis...@ietf.org; bess-cha...@ietf.org;
> bess@ietf.org; Matthew Bocci 
> Subject: Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04:
> (with DISCUSS and COMMENT)
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-bess-rfc5549revision-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/
>
>
>
> --
> DISCUSS:
> --
>
> An easy one, but necessary IMHO:
>
> I'm confused by the IANA Considerations section.  It looks like a verbatim
> copy from RFC 5549 which made the original registration for "Extended Next
> Hop Encoding", but this isn't actually a new registration.  Shouldn't this
> therefore be something like the following?
>
> NEW:
>
> RFC 5549 added "Extended Next Hop Encoding" to the Capability Codes
> registry, which was created by [RFC5492].  IANA is requested to update the
> definition of that entry to refer instead to this document.
>
>
> --
> COMMENT:
> --
>
> Thanks for this document.  It was easy to read even for people like me who
> don't get involved in routing too much.
>
> Thank you also for the shepherd writeup, which (unlike most lately)
> actually answered the question "Why is this the proper type of RFC?"
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: (with DISCUSS and COMMENT)

[slitkows.ietf]

Hi Murray,

I have uploaded a new revision that clarifies the IANA section.

-Original Message-
From: Murray Kucherawy via Datatracker  
Sent: mercredi 26 août 2020 21:01
To: The IESG 
Cc: draft-ietf-bess-rfc5549revis...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Matthew Bocci 
Subject: Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: 
(with DISCUSS and COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-rfc5549revision-04: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/



--
DISCUSS:
--

An easy one, but necessary IMHO:

I'm confused by the IANA Considerations section.  It looks like a verbatim copy 
from RFC 5549 which made the original registration for "Extended Next Hop 
Encoding", but this isn't actually a new registration.  Shouldn't this 
therefore be something like the following?

NEW:

RFC 5549 added "Extended Next Hop Encoding" to the Capability Codes registry, 
which was created by [RFC5492].  IANA is requested to update the definition of 
that entry to refer instead to this document.


--
COMMENT:
--

Thanks for this document.  It was easy to read even for people like me who 
don't get involved in routing too much.

Thank you also for the shepherd writeup, which (unlike most lately) actually 
answered the question "Why is this the proper type of RFC?"




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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-na-flags-05

[Rabadan, Jorge (Nokia - US/Mountain View)]

Robert,

Thank you very much for the review. Great points.
Please see in-line with [Jorge]. All the changes will be included in the next 
revision.
Thank you!
Jorge

From: Robert Sparks via Datatracker 
Date: Tuesday, August 18, 2020 at 6:11 PM
To: gen-...@ietf.org 
Cc: draft-ietf-bess-evpn-na-flags@ietf.org 
, last-c...@ietf.org 
, bess@ietf.org 
Subject: Genart last call review of draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
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-na-flags-05
Reviewer: Robert Sparks
Review Date: 2020-08-18
IETF LC End Date: 2020-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC but with nits to
address before publication

The protocol being defined seems fine, and the IANA considerations are well
constructed. I have a nagging feeling that there are new security concerns this
introduces, but haven't been able to identify anything specific. I appreciate
that the document discusses what happens when a bad-actor introduces
intentionally mis-configured flags.

Editorial Issues:

The Abstract is full of acronyms that are not universally understood, and it
buries the point of the document. Please consider rewriting to focus more
specifically on the goal of the draft (see the introduction in the shepherd's
writeup), keeping in mind that the abstract should make sense to people who
don't know yet what PE stands for. Much of what you currently have in the
Abstract can be left to the Introduction. I expect a  shorter (two or three
sentence) abstract will suit the document better.
[Jorge] we simplified the abstract as follows, hopefully it addresses your 
comment:
   Ethernet Virtual Private Network (EVPN) uses MAC/IP Advertisement
   routes to advertise locally learned MAC and IP addresses associated
   to host or routers.  The remote Provider Edge (PE) routers may use
   this information to populate their Address Resolution Protocol (ARP)
   or Neighbor Discovery (ND) tables and then reply locally to ARP
   Requests or Neighbor Solicitation messages on behalf of the owner of
   the IP address.  However, the information conveyed in the MAC/IP
   route may not be enough for the remote PE to reply to local ARP or ND
   requests.  This document defines an Extended Community that is
   advertised along with an EVPN MAC/IP Advertisement route and carries
   information relevant to the ARP/ND resolution, so that an EVPN PE
   implementing a proxy-ARP/ND function can reply to ARP Requests or
   Neighbor Solicitations with the correct information.



In section 3.2: The list of three things in the list under "R and O Flags
processing" are all processing steps. But the list of 6 things under "I Flag
processing" are not all processing steps. Please change the list to only
include processing steps, and move the examples and commentary to regular
paragraphs after the processing has been specified.

Consider moving the third top-level bullet in 3.2 ("MUST be ignored") to be the
first bullet, and after that bullet say "otherwise".
[Jorge] ok, section 3.2 changed as follows:

3.2.  Reception of the EVPN ARP/ND Extended Community



   In addition to the procedures specified in [RFC7432] a PE receiving a

   MAC/IP Advertisement route will process the EVPN ARP/ND Extended

   Community as follows:



   o  The R, O and I Flags MUST be ignored if they are advertised along

  with an EVPN MAC/IP Advertisement route that does not contain an

  IP (IPv4 or IPv6) address.  Otherwise they are processed as

  follows.



   o  R and O Flags processing:



  *  If the EVPN MAC/IP Advertisement route contains an IPv6 address

 and the EVPN ARP/ND Extended Community, the PE MUST add the R

 and O Flags to the ND entry in the ND or proxy-ND table and use

 that information in Neighbor Advertisements when replying to a

 Solicitation for the IPv6 address.



  *  If no EVPN ARP/ND Extended Community is received along with the

 route, the PE will add the default R and O Flags to the entry.

 The default R Flag SHOULD be an administrative choice.  The

 default O Flag SHOULD be 1.



  *  A PE MUST ignore the received R and O Flags for an EVPN MAC/IP

 Advertisement route that contains an IPv4->MAC pair.



   o  I Flag processing:



  *  A PE receiving an EVPN MAC/IP Advertisement route containing an

 IP->MAC and the I Flag set SHOULD install the IP->MAC entry in

 the ARP/ND or proxy-ARP/ND table as an "Immutable binding".

 This Immutable binding entry will override an existing non-

[bess] I-D Action: draft-ietf-bess-rfc5549revision-05.txt

[internet-drafts]

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   : Advertising IPv4 Network Layer Reachability 
Information with an IPv6 Next Hop
Authors : Stephane Litkowski
  Swadesh Agrawal
  Krishna Muddenahally Ananthamurthy
  Keyur Patel
Filename: draft-ietf-bess-rfc5549revision-05.txt
Pages   : 14
Date: 2020-08-31

Abstract:
   Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop
   address families is determined by the Address Family Identifier (AFI)
   and the Subsequent Address Family Identifier (SAFI).  The AFI/SAFI
   definitions for the IPv4 address family only have provisions for
   advertising a Next Hop address that belongs to the IPv4 protocol when
   advertising IPv4 Network Layer Reachability Information (NLRI) or
   VPN-IPv4 NLRI.

   This document specifies the extensions necessary to allow advertising
   IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to
   the IPv6 protocol.  This comprises an extension of the AFI/SAFI
   definitions to allow the address of the Next Hop for IPv4 NLRI or
   VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of
   the Next Hop to determine which of the protocols the address actually
   belongs to, and a BGP Capability allowing MP-BGP Peers to dynamically
   discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with
   an IPv6 Next Hop. This document obsoletes RFC5549.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-rfc5549revision-05
https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc5549revision-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-rfc5549revision-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

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-rfc5549revision-04: (with COMMENT)

[Stephane Litkowski (slitkows)]

Thanks,

I have fixed all what was mentioned below for the next revision.

Stephane


-Original Message-
From: Acee Lindem (acee)  
Sent: lundi 17 août 2020 13:46
To: Erik Kline ; The IESG 
Cc: matthew.bo...@nokia.com; bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-rfc5549revis...@ietf.org
Subject: Re: [bess] Erik Kline's No Objection on 
draft-ietf-bess-rfc5549revision-04: (with COMMENT)

Hi Erik, 

On 8/17/20, 7:32 AM, "Acee Lindem (acee)"  wrote:

Hi Erik,

On 8/16/20, 7:50 PM, "BESS on behalf of Erik Kline via Datatracker" 
 wrote:

Erik Kline has entered the following ballot position for
draft-ietf-bess-rfc5549revision-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/



--
COMMENT:
--

[[ comments ]]

[ section 3 ]

* Perhaps "8-octet RD is set to zero" -> "8-octet RD set to zero"

[ section 4 ]

* Perhaps "for which there is already solution" ->
  "for which there is already a solution"

* "from the onset" -> "from the outset", I think

I believe either is correct and I think "onset" is more common.

I guess "onset" usually implies the start of something unpleasant, which would 
hopefully not be the case for supporting next-hops of both AFs __, so I would 
agree with your suggested change. Or it could simply be changed to "from the 
beginning" to avoid any confusion.

https://www.differencebetween.com/difference-between-onset-and-vs-outset/


Thanks,
Acee

Thanks,
Acee

[ section 6.2 ]

* "IPV4" -> "IPv4"

[ section 6.3 ]

* "IPV4" -> "IPv4"



___
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