Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 29 Jan 2019 22:41:54 +0000

Please refer to my reply inline.

From: BESS <[email-masked]> on behalf of Krzysztof Szarkowicz <[email-masked]>
Date: Wednesday, August 8, 2018 at 10:55 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Hello working group,

I have two comments regarding section 3.1.

* Section 3.1. refers only to “ARP” or “ARP reply”. Given the fact, it is applicable to IPv6 as well, it should refer to ND NS/NA messages as well, I believe.

OK. Added ND NS along with ARP request  and ND NA along with ARP reply.

* In the last paragraph of Section 3.1:

>  Irrespective of using only the anycast address or both anycast and

   non-anycast addresses on the same IRB, when a TS sends an ARP request

   to the PE that is attached to, the ARP request is sent for the

   anycast IP address of the IRB interface associated with the TS's

   subnet.
If both anycast and non-anycast addresses are on the IRB, it is legitimate that TS sends NS/ARP request to resolve either anycast (e.g. to resolve IP address of default gateway configured on TS), or to resolve non-anycast (e.g. ping towards non-anycast address was initiated on TS). Therefore, presuming that TS sends ARP request to resolve only anycast IP is not fully correct, I believe. Thus, wording of this paragraph should cover two cases (NS/ARP request to resolve anycast, and NS/ARP request to resolve non-anycast IP).

TS is not supposed to use non-anycast addresses on the IRB interface because if OAM pinging is needed by the TS to the IRB interface, it can do that using anycast address. Non-anycast addresses are intended to be used by network operator for its OAM within the EVPN network.

>> the PE1 sends an ARP reply with the MACx which is the anycast

   MAC address of that IRB interface.
NA/ARP reply has multiple MAC related fields:

* Destination MAC (in Ethernet header)
* Source MAC (in Ethernet header)
* Sender hardware address (in the payload)
* Target hardware address (in the payload)

It is not ultimately clear from the text, if 'Source MAC (in Ethernet header)’ or 'Sender hardware address (in the payload)’, or both, should be populated with MACx. As I see it, in case of both anycast and non-anycast address is used on IRB, the behavior should be:

Since we are talking about only anycast addresses to be used by the TS, then it should be clear that only anycast MAC address will be used  - i.e., in both source MAC (in Ethernet header) and Sender hardware address (in the payload). However to make that crystal clear, I modified the 1st half of the last para as follow:
“Irrespective of using only the anycast address or both anycast and non-anycast addresses on the same IRB, when a TS sends an ARP request or ND Neighbor Solicitation (NS) to the PE that is attached to, the request is sent for the anycast IP address of the IRB interface associated with the TS's subnet and the reply will use anycast MAC address (in both Source MAC in the Ethernet header and Sender hardware address in the payload).”

Cheers,
Ali

* TS sends and NS/ARP request for the anycast address:
   -> PE sends and NA/ARP reply with anycast MAC in both 'Source MAC (in Ethernet header)’ and 'Sender hardware address (in the payload)’ fields

* TS sends and NS/ARP request for the non-anycast address:
   -> PE sends and NA/ARP reply with non-anycast MAC in both 'Source MAC (in Ethernet header)’ and 'Sender hardware address (in the payload)’ fields

Otherwise, if only 'Sender hardware address (in the payload)’ is populated with anycast/non-anycast MAC (depending, which IP address is being resolved), and 'Source MAC (in Ethernet header)’  is always populated with no-anycast MAC (in implementations mimicking RFC 5798, Section 8.1.2/8.2.2/8.2.3 behavior, which explicitly disables usage of V-MAC in the 'Source MAC (in Ethernet header)’), the L2 domain (L2 switches) between PE and CE will not learn anycast MAC, thus resulting in unknown unicast flooding being used on these switches to reach anycast MAC. This is undesirable behavior and should be avoided.

Thanks,
Krzysztof

On 2018-Aug-08, at 16:03, [email-masked]<mailto:[email-masked]> wrote:

Hello working group,

This email starts a two-week Working Group Last Call on draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].

A significant amount of update has been introduced since the previous WGLC. Please review the updates and provide your feedback.

This poll runs until *the 22th of August*.

Thank you

Stéphane, Matthew
bess chairs

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Dinter-2Dsubnet-2Dforwarding_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=M3KXSZ0muPPn2zxPT05cRmBqEF0itd-o0h975Aqb6pc&s=EBLyh0PcaHNBNxqOaSANy9lFfsov9flJfYmoJf44EKI&e=>

_________________________________________________________________________________________________________________________

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=M3KXSZ0muPPn2zxPT05cRmBqEF0itd-o0h975Aqb6pc&s=I7TJcUnVRhayAA2yOuAxBtRnkwv7eG_mHiM9ggVaPsc&e=>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 29 Jan 2019 23:03:32 +0000

Please refer to my reply inline marked with “AS>”

From: BESS <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Wednesday, August 15, 2018 at 12:20 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Hi Stephane, Authors,

I support advancement. This is a useful optimization that has been implemented .

Two comments:

  1.  Call the new BGP Community “Router MAC” rather than “Router’s MAC”.

AS>  It is already registered with IANA as “Router’s MAC”, so I am reluctant to change it at this point. However, if RFC editor make the same complain, then I will change it then.

  1.   Consistently use “TSes” to refer to multiple Tenant Systems and “TS’s” to refer to an address or other entity processed by a Tenant System.

AS> OK. Done.

Cheers,
Ali

I have some other editorial comments that I will pass to the authors.

Thanks,
Acee

From: BESS <[email-masked]> on behalf of Stephane Litkowski <[email-masked]>
Date: Wednesday, August 8, 2018 at 10:03 AM
To: "[email-masked]" <[email-masked]>
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Hello working group,

Thank you

Stéphane, Matthew

bess chairs

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

Thank you.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 29 Jan 2019 23:19:45 +0000

Please refer to my replie inline marked with “AS>”

From: BESS <[email-masked]> on behalf of "Luc Andre Burdet (lburdet)" <lburdet=[email-masked]>
Date: Tuesday, August 21, 2018 at 10:56 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Support.

This is an important draft and is implemented;

​

  1.  ​I echo Acee's comment re: "Router MAC" for readability

AS> I also echo my reply to Acee’s comment ☺

(2) The document often refers to two Route-targets (MAC-VRF & IP-VRF) which is overly restrictive.

I would propose language more to the effect of MAC/IP must be advertised with two sets of RTs

AS> “two Route targets” are used when the document talks about Route-Type-2 – which is in context of a single EVI for MAC-VRF and IP-VRF.

Cheers,

Ali

    RFC7432:  EVPN route MAY carry one or more Route Target (RT) attributes.​

vs. for example:

   This route MUST be advertised with two route targets - one

   corresponding to the MAC-VRF of the tenant's subnet and another

   corresponding to the tenant's IP-VRF.

Thanks,

Luc André​ Burdet

________________________________
From: BESS <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: August 8, 2018 10:03 AM
To: [email-masked]
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Hello working group,

Thank you

Stéphane, Matthew

bess chairs

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Dinter-2Dsubnet-2Dforwarding_&d=DwMFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=VU__J6JcQT-jBVQ7BEimvCCgmWvdQpMw-VpXgY39-m8&s=nxXUe1WHmYhAFGEn-xeZth_6kTo5eqy6A9BQEKXV-9g&e=>

Thank you.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 31 Jan 2019 02:24:49 +0000

Hi Stephane,

I have addressed all the comments from the people you mentioned in your email below as well as some additional comment received after WGLC ended. I will check in a new rev. shortly.

Cheers,
Ali

From: BESS <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, September 3, 2018 at 1:23 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

The document has a good level of support to progress. However there are several comments raised that have not been answered yet.

Authors,

Could you please address the comments that have been raised on the list (from Acee, Krysztof, and Luc Andre) ?

Thanks,

Stephane

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 08, 2018 16:04
To: [email-masked]
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Hello working group,

Thank you

Stéphane, Matthew

bess chairs

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Dinter-2Dsubnet-2Dforwarding_&d=DwMFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=kOD-tH4A7gYmQNezsuKId7paMuRTEhEjbMZGYejRAe8&s=e41J_o-FxoQz0_wUBr2xX40neEKq4pRJ4aLE6-9KLMA&e=>

Thank you.

Thank you.