Re: [bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Hi Alvaro,



Thank you very much for reviewing!

Will incorporate the changes in the next revision.

Please see in-line with [jorge].



Jorge



--------------------------------------------------------------------------------------------------------------------

From: Alvaro Retana via Datatracker <[e-mail]>

Date: Monday, January 18, 2021 at 10:36 PM

To: The IESG <[e-mail]>

Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>

Subject: Alvaro Retana's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)

Alvaro Retana has entered the following ballot position for

draft-ietf-bess-evpn-proxy-arp-nd-11: 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-proxy-arp-nd/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



As mentioned in the Introduction:



   This document describes the Proxy-ARP/ND function in [RFC7432]

   networks, augmented by the capability of the ARP/ND Extended

   Community [I-D.ietf-bess-evpn-na-flags].  From that perspective this

   document updates [RFC7432].



Even with this statement, the purpose of this document and the relationship

between it, rfc7432 and I-D.ietf-bess-evpn-na-flags is not completely clear to

me.  I would like to understand the following:



- Why isn't this description included in I-D.ietf-bess-evpn-na-flags if the

  functionality is introduced there?

[jorge] The extended community is introduced in [I-D.ietf-bess-evpn-na-flags], but the use of the extended community is not limited to RFC7432’s proxy-arp/nd in the mentioned document, but it can be used for any ARP/ND function, including ARP/ND resolution in IRB interfaces. draft-ietf-bess-evpn-proxy-arp-nd focuses purely on the proxy-arp/nd aspects of RFC7432 networks.





- This document formally Updates rfc7432, but I-D.ietf-bess-evpn-na-flags

  didn't. How can the description of the function Update rfc7432 if the

  functionality doesn't?  What exactly is the update to rfc7432?

[jorge] RFC7432 talks about this proxy-arp/nd capability in section 10, but as you can see, leaves many aspects to the implementation. draft-ietf-bess-evpn-proxy-arp-nd details all those aspects. This document was initially considered an informational draft, but after discussing with Martin we changed it to Standards track, since we thought RFC7432 should have provided this level of details in the first place.





- The WG developed this document alongside I-D.ietf-bess-evpn-na-flags, but it

  is not referenced from there.  Why?

[jorge] I-D.ietf-bess-evpn-proxy-arp-nd makes use of I-D.ietf-bess-evpn-na-flags, but the other way around is not necessarily true. We can add it as informational reference if you think it is needed.





Besides those high-level questions, I have a set of comments that are mostly

related to the normative language used.  I would like to see these issues

addressed before publication.





(1) §3.1 recommends this:



   The provisioned static IP->MAC entry SHOULD be advertised in EVPN with an

   ARP/ND Extended Community where the Immutable ARP/ND Binding Flag flag (I)

   is set to 1, as per [I-D.ietf-bess-evpn-na-flags].



...but I-D.ietf-bess-evpn-na-flags requires the behavior, from §3.1:



   o  If an IP->MAC pair is static (it has been configured) the

      corresponding MAC/IP Advertisement route MUST be sent along with

      an ARP/ND Extended Community with the I Flag set.

[jorge] ok, changed to MUST.





(2) §3.1: "An entry MAY associate a configured static IP to a list of

potential MACs, i.e. IP1->(MAC1,MAC2..MACN)."   s/MAY/may  This is not a

normative statement, but just a fact.

[jorge] that’s right, changed.







(3) The phrase "MUST/SHOULD be learned" is used several times, but the

normative action doesn't seem to apply to learning, but to what is required

to learn.  For example, from §3.1:



   a.  Proxy-ARP dynamic entries:



          They SHOULD be learned by snooping any ARP packet (Ethertype

          0x0806) received from the CEs attached to the BD.



A better wording would be something like: "The PE SHOULD snoop all ARP packets

received from the CEs in order to learn dynamic entries."   The normative

action is clear: snoop!



Please review/update other places where this phrase is used.

[jorge] ok, I changed the occurrences in section 3.1.





(4) §3.1: "They SHOULD be learned by snooping any ARP packet..."  Why is this

action only recommended? When would a PE not snoop the ARP packets? IOW, why

is MUST not used?  Note that neither rfc7432/I-D.ietf-bess-evpn-na-flags use

Normative language then talking about snooping.

[jorge] ok, changed to MUST





(5) §3.1: "They SHOULD be learned out of the Target Address and TLLA information

in NA messages (Ethertype 0x86DD, ICMPv6 type 136) received from the CEs

attached to the BD."  Same questions...

[jorge] ok, changed to MUST







(6) §3.1: "A Proxy-ND implementation SHOULD NOT learn IP->MAC entries from NS

messages, since they don't contain the R Flag required by the Proxy-ND reply

function."  If the R flag is required, when is it ok to learn from NS messages?

IOW, why is this action not a requirement?

[jorge] ok, changed to MUST







(7) §3.1.1: "the node MUST remove that router from the Default Router

List...as specified in [RFC4861] section 7.3.3."   This is in fact already

specified in rfc4861, there's no need to specify it here again.  s/MUST/must

[jorge] changed, thanks.





(8) §3.1.1: "Static entries SHOULD have the R Flag information added by the

management interface.  The O Flag information MAY also be added by the

management interface."   It sounds as if the action here is to add the flag,

right?   Perhaps: "The R Flag information SHOULD be added...for static

entries. ..."

[jorge] ok, changed





When is it ok to not configure the flags?  Why is the configuration not

required?  The text in I-D.ietf-bess-evpn-na-flags seems to assume that it is

a requirement (but no normative language is used there): "R and O Flag

values...are...configured in case of static entries." (§3.1)   What if the

value is not configured, what is the default?

[jorge] changed the default to 1.





(9) §3.2:



   a.  When replying to ARP Request or NS messages, the PE SHOULD use

       the Proxy-ARP/ND entry MAC address as MAC SA.  This is

       RECOMMENDED so that the resolved MAC can be learned in the MAC

       FIB of potential layer-2 switches sitting between the PE and the

       CE requesting the Address Resolution.



It seems to me that the use as MAC SA should be required and not just

recommended "so that the resolved MAC can be learned in...layer-2 switches".

Why is that not the case?

[jorge] the PE may choose to use its own MAC as the MAC SA, and that is okay if there are no layer-2 switches between the PE and the host. Even if there is a layer-2 switch, the host still resolves the ARP/Neighbor. This is a recommendation to avoid unnecessary flooding, but not a requirement.





(10) §3.2: "A PE SHOULD NOT reply to ARP probes received from the CEs."  When

is it ok for the PE to reply?  IOW, why is the behavior recommended and not

required?

[jorge] an ARP probe is destined to end hosts/CEs. I changed it to MUST NOT.





(11) §3.2: "A PE SHOULD only reply to ARP-Request and NS messages with the

format specified in [RFC0826] and [RFC4861] respectively."  When is it ok to

reply using a different format, and what format would that be?

[jorge] good point, changed to MUST





(12) §3.3: "The operator SHOULD be able to activate this option with one of

the following parameters..."  For the operator to be able to do anything, the

implementation has to support the functionality.  It might be better to

recommend the implementation...

[jorge] added: “The implementation of a 'unicast-forward' function is RECOMMENDED”





(13) §5.1: "Existing mitigation solutions, such as the ARP-Sponge daemon

[ARP-Sponge] MAY also be used in this scenario."   This seems to just be an

example: s/MAY/may

[jorge] that’s correct, I changed it.





(14) §6: "IXPs MUST still employ additional security mechanisms that protect the

peering network..."  Which are the required mechanisms?

[jorge] I changed this to: “IXPs must still employ additional security mechanisms that protect the peering network as per the established BCPs such as…”





(15) §6: "IXPs...SHOULD follow established BCPs such as the ones described in

[Euro-IX-BCP]."  When is it ok to not follow "established BCPs"?  Seeing that

you are normatively recommending something, please add specific mechanisms,

not just an example.

[jorge] I think the normative language is wrong here, so I changed it as per the above comment. BCPs for IXPs are out of the document’s scope.





(16) The references to ARP-Sponge and Euro-IX-BCP don't include enough

information to access the documents.  Is there a stable link that can be

included?

[jorge] added, thanks.