Re: [bess] [EXTERNAL] EVPN service carving with ingress VLAN translation

[Muthu Arul Mozhi Perumal]

Hi Sasha,

Thanks for your response. I agree, using a manually configured ID is the
best option when VID translation is performed at one or more ingress PEs
that are part of the multi-homed group to obtain a predictable default DF
election result..

That said, the current situation is, different vendors seem to use
different VIDs for DF election when VID translation is performed at the
ingress PE; some seem to use the translated VID and some even the BGP
router ID when the translation rule removes the tag entirely (making it
untagged) without proving a configurable ID..

How about adding some text to rfc7432bis section 6?


   An Ethernet Tag ID is a 32-bit field containing either a 12-bit or
   24-bit identifier that identifies a particular broadcast domain
   (e.g., a VLAN) in an EVPN instance.  The 12-bit identifier is called
   the VLAN ID (VID).  An EVPN instance consists of one or more
   broadcast domains (one or more VLANs).  VLANs are assigned to a given
   EVPN instance by the provider of the EVPN service.  A given VLAN can
   itself be represented by multiple VIDs.  In such cases, the PEs
   participating in that VLAN for a given EVPN instance are responsible
   for performing VLAN ID translation to/from locally attached CE
   devices.



   An Ethernet Tag ID is a 32-bit field containing either a 12-bit or
   24-bit identifier that identifies a particular broadcast domain
   (e.g., a VLAN) in an EVPN instance.  The 12-bit identifier is called
   the VLAN ID (VID).  An EVPN instance consists of one or more
   broadcast domains (one or more VLANs).  VLANs are assigned to a given
   EVPN instance by the provider of the EVPN service.  A given VLAN can
   itself be represented by multiple VIDs.  In such cases, the PEs
   participating in that VLAN for a given EVPN instance are responsible
   for performing VLAN ID translation to/from locally attached CE
   devices.


*If a PE performs VID translation of frames received from   locally
attached CE (including removing all tags making it untagged),   the PE
SHOULD provide a configurable ID for the EVPN instance for   the purpose of
DF election.*


Regards,
Muthu

On Tue, Feb 15, 2022 at 6:53 PM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:

> Muthu,
>
> Quoting from Section 3 of 7432bis
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-02#section-3>
> :
>
>
>
>Ethernet Tag:  Used to represent a BD that is configured on a given
>
>   ES for the purposes of DF election and  identification
>
>   for frames received from the CE.  Note that any of the following
>
>   may be used to represent a BD: VIDs (including Q-in-Q tags),
>
>   configured IDs, VNIs (Virtual Extensible Local Area Network
>
>   (VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service
>
>   Instance Identifiers), etc., as long as the representation of the
>
>   BDs is configured consistently across the multihomed PEs attached
>
>   to that ES.
>
>
>
> As I see it, using manually configured IDs can address your concerns.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@rbbn.com
>
>
>
> *From:* BESS  *On Behalf Of * Muthu Arul Mozhi
> Perumal
> *Sent:* Tuesday, February 15, 2022 1:23 PM
> *To:* bess@ietf.org
> *Subject:* [EXTERNAL] [bess] EVPN service carving with ingress VLAN
> translation
>
>
>
> Hi,
>
>
>
> Though rfc7432bis recommends VLAN translation to be performed at the
> disposition PE (for VLAN-based and VLAN-aware bundle services), I believe
> there are existing deployments where VLAN translation is performed at the
> ingress PE. In this scenario, is there any guideline on whether service
> carving is to be performed based on the original VLAN or translated VLAN?
>
>
>
> I think this cannot be left implementation specific, since DF election is
> a distributed algorithm and should yield the same result in all PEs that
> are part of the multi-homed group.
>
>
>
> Any feedback would be helpful..
>
>
>
> Regards,
>
> Muthu
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/

[bess] EVPN service carving with ingress VLAN translation

[Muthu Arul Mozhi Perumal]

Hi,

Though rfc7432bis recommends VLAN translation to be performed at the
disposition PE (for VLAN-based and VLAN-aware bundle services), I believe
there are existing deployments where VLAN translation is performed at the
ingress PE. In this scenario, is there any guideline on whether service
carving is to be performed based on the original VLAN or translated VLAN?

I think this cannot be left implementation specific, since DF election is a
distributed algorithm and should yield the same result in all PEs that are
part of the multi-homed group.

Any feedback would be helpful..

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

[bess] EVPN IRB - Clarifications on MAC/IP route with only the MAC address

[Muthu Arul Mozhi Perumal]

Hi,

RFC9135 describes some scenarios where a PE withdraws a MAC/IP route with
only the MAC address if it had advertised such a route before. Here is one
such scenario:

   On the source NVE, an age-out timer (for the silent host that has
   moved) is used to trigger an ARP probe.  This age-out timer can be
   either an ARP timer or a MAC age-out timer, and this is an
   implementation choice.  The ARP request gets sent both locally to all
   the attached TSs on that subnet as well as to all the remote NVEs
   (including the target NVE) participating in that subnet.

*The source   NVE also withdraws the EVPN MAC/IP Advertisement route with
only the   MAC address (if it has previously advertised such a route).*


Have some questions:
1) If the source NVE had allocated MPLS Label1 on a per MAC basis, is the
source NVE expected to retain Label1 even after withdrawing the MAC/IP
route with only the MAC address? Otherwise, it would invalidate the MAC/IP
route with both the MAC and IP addresses since Label1 is mandatory and
expected to be valid in that route, right?

2) If the source NVE re-advertises the MAC/IP route with both the MAC and
IP addresses after withdrawing the MAC/IP route with only the MAC address,
say because of a route refresh request, should the re-advertised route
carry only the IP VRF Route Target?

3) Can the user assign the same route target for both the IP and MAC VRFs
and use it to match against both? RFC9135 does not explicitly prohibit, but
that may cause problems, for e.g. in #2 above, right?

Comments/clarifications would be helpful..

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

Re: [bess] WG and IPR poll adoption poll for draft-krattiger-evpn-modes-interop

[Muthu Arul Mozhi Perumal]

Hi Stephane,

That's fine. Hoping to hear from the authors on my comments..

Regards,
Muthu

On Fri, May 7, 2021 at 9:14 PM  wrote:

> Hi Muthu,
>
>
>
> (Speaking as co-chair)
>
>
>
> Thanks for the feedback on the intended status. This has to be clarified
> however this is not a blocking point for the adoption. We have time to
> figure out the intended status of the document with the authors/WG and
> adjust the text accordingly.
>
>
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:* Muthu Arul Mozhi Perumal 
> *Sent:* vendredi 23 avril 2021 13:15
> *To:* slitkows.i...@gmail.com
> *Cc:* bess@ietf.org; bess-cha...@ietf.org
> *Subject:* Re: [bess] WG and IPR poll adoption poll for
> draft-krattiger-evpn-modes-interop
>
>
>
> I support the adoption. However, have a few comments:
>
>
>
> The intended status of the draft is Informational, but it doesn't look
> right.
>
>
>
> The abstract says:
>
>   This document specifies how the different EVPN
>
>functional modes and types can interoperate with each other. This
>document doesn't aim to redefine the existing functional modes
> *but   extend them for interoperability*.
>
>
>
> In addition, the draft has multiple normative statements. Hence,
> believe the intended status should be standards track instead..
>
>
>
> Section 4.2 says:
>
>With PE2 operating in Symmetric IRB and with enabled interop mode,
>the MAC/IP route from PE1 (Asymmetric IRB) is processed in the
>respective bridging, routing and adjacency table. Based on the Route-
>Target for MAC-VRF1, the MAC address M1 will be imported into MAC-
>VRF1 respectively and placed within BD0.
>
> * In addition, the host-   binding information M1/IP1 MUST be installed
> within PE2s adjacency   table.*
>
>
>
> For a PE operating in symmetric IRB mode, it is not required to install
> M1/P1 in the ARP/ND/adjacency table as
> per draft-ietf-bess-evpn-inter-subnet-forwarding. Hence, I think this draft
> is updating/extending draft-ietf-bess-evpn-inter-subnet-forwarding.
>
>
>
> The draft has the foll. description for Figure 2:
>
>The IRB interfaces for a common MAC-VRF/BD on
>PE1 and PE2 use the *same IP address*. With the difference of the IRB
>modes between PE1 (Asymmetric IRB) and PE2 (Symmetric IRB), there is
>a difference in the MPLS Label presence as part of the MAC/IP routes
>exchanged between the PEs.
>
>
>
> I guess it should say "same IP address and MAC address". Otherwise, it is
> not necessary to install M1/P1 in PE2's adj table. If PE2 receives a packet
> destined to P1, PE2 will initiate a glean procedure causing the host having
> (M1, P1) to respond. The response will reach PE2, so PE2 will install in
> its adjacency. The problem occurs only when both PE1 and PE2 use the same
> anycast default gateway IP and MAC addresses (which is also the recommended
> option as per draft-ietf-bess-evpn-inter-subnet-forwarding), in which case
> the response from the host will be locally consumed by PE1.
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Mon, Apr 19, 2021 at 11:36 PM  wrote:
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-krattiger-evpn-modes-interop-03 [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 will
> not  progress without answers from all of 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 4th May 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1]  https://datatracker.ietf.org/doc/draft-krattiger-evpn-modes-interop/
>
>
>
> ___
> 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] Implications of using non-anycast IRB GW MAC address

[Muthu Arul Mozhi Perumal]

draft-ietf-bess-evpn-inter-subnet-forwarding describes two ways of
assigning the default GW MAC address in section 4.1:


   1.  All the PEs for a given tenant subnet use the same anycast
   default gateway IP and MAC addresses.  On each PE, this default
   gateway IP and MAC addresses correspond to the IRB interface
   connecting the BT associated with the tenant's VLAN to the
   corresponding tenant's IP-VRF.

   2.  Each PE for a given tenant subnet uses the same anycast default
   gateway IP address but its own MAC address.


It says that option-1 is recommended because of the ease of anycast MAC
address provisioning. However, option-2 is not prohibited. I think using a
non-anycast default GW MAC address has certain implications on the mobility
procedures (section 7) that is not well described in the draft:

Section 7.1 says the following:

   The source NVE upon receiving this MAC/IP Advertisement route,
   realizes that the MAC has moved to the target NVE.  It updates its
   MAC-VRF and IP-VRF table accordingly with the adjacency information
   of the target NVE.  In the case of the asymmetric IRB, the source NVE
   also updates its ARP table with the received adjacency information
   and in the case of the symmetric IRB, the source NVE removes the
   entry associated with the received (MAC, IP) from its local ARP
   table.  It then withdraws its EVPN MAC/IP Advertisement route.




*   Furthermore, it sends an ARP probe locally to ensure that the MAC is
 gone.  If an ARP response is received, the source NVE updates its ARP
 entry for that (IP, MAC) and re-advertises an EVPN MAC/IP   Advertisement
route for that (IP, MAC) along with MAC Mobility   Extended Community with
the sequence number incremented by one.*  The
   source NVE also exercises the MAC duplication detection procedure in
   section 15.1 of [RFC7432].


Now, if the source NVE uses a non-anycast default GW MAC address, then it
will receive an ARP response for its ARP probe since the ARP response will
be sent back to the non-anycast MAC address. This may cause the source NVE
to think that the TS has moved back, resulting in re-advertisement of the
EVPN MAC/IP route for that (IP, MAC) along with the MAC mobility EC with
the seq. number incremented by one.

To avoid this problem, source NVE needs to understand that the ARP response
was received over the MPLS/IP core instead of over the access-facing IRB
interface and discard it.

In section 7.2 the draft says the following:

   o  The target NVE passes the ARP request to its locally attached TSes
  and *when it receives the ARP response*, it updates its IP-VRF and
  ARP table with the host (MAC, IP) information.  It also sends an
  EVPN MAC/IP Advertisement route with both the MAC and IP addresses
  filled in along with MAC Mobility Extended Community with the
  sequence number set to the same value as the one for MAC-only
  advertisement route it sent previously.


In the above, the ARP request is originated by the source NVE. Hence, if
the source NVE uses a non-anycast default gateway MAC address, then the ARP
response will be sent back to the source NVE, instead of being locally
consumed by the target NVE and causing it to perform the procedures
described above.

In section 7.3, the draft says the following:

   The target NVE passes the ARP request to its locally attached TSes
   and *when it receives the ARP response*, it updates its MAC-VRF, IP-
   VRF, and ARP table with the host (MAC, IP) and local adjacency
   information (e.g., local interface).  It also sends an EVPN MAC/IP
   advertisement route with both the MAC and IP address fields filled in
   along with MAC Mobility Extended Community with the sequence number
   incremented by one.


The problem here is the same if the source NVE uses a non-anycast default
GW MAC address..

Should there be a better description in the draft on the implications of
using non-anycast default GW MAC address?

Are there IRB deployments using non-anycast default GW MAC address for
hosts/servers (other than the one used only for OAM)?

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

Re: [bess] WG and IPR poll adoption poll for draft-krattiger-evpn-modes-interop

[Muthu Arul Mozhi Perumal]

I support the adoption. However, have a few comments:

The intended status of the draft is Informational, but it doesn't look
right.

The abstract says:
  This document specifies how the different EVPN
   functional modes and types can interoperate with each other. This
   document doesn't aim to redefine the existing functional modes
*but   extend them for interoperability*.

In addition, the draft has multiple normative statements. Hence,
believe the intended status should be standards track instead..

Section 4.2 says:
   With PE2 operating in Symmetric IRB and with enabled interop mode,
   the MAC/IP route from PE1 (Asymmetric IRB) is processed in the
   respective bridging, routing and adjacency table. Based on the Route-
   Target for MAC-VRF1, the MAC address M1 will be imported into MAC-
   VRF1 respectively and placed within BD0.

* In addition, the host-   binding information M1/IP1 MUST be installed
within PE2s adjacency   table.*

For a PE operating in symmetric IRB mode, it is not required to install
M1/P1 in the ARP/ND/adjacency table as
per draft-ietf-bess-evpn-inter-subnet-forwarding. Hence, I think this draft
is updating/extending draft-ietf-bess-evpn-inter-subnet-forwarding.

The draft has the foll. description for Figure 2:
   The IRB interfaces for a common MAC-VRF/BD on
   PE1 and PE2 use the *same IP address*. With the difference of the IRB
   modes between PE1 (Asymmetric IRB) and PE2 (Symmetric IRB), there is
   a difference in the MPLS Label presence as part of the MAC/IP routes
   exchanged between the PEs.

I guess it should say "same IP address and MAC address". Otherwise, it is
not necessary to install M1/P1 in PE2's adj table. If PE2 receives a packet
destined to P1, PE2 will initiate a glean procedure causing the host having
(M1, P1) to respond. The response will reach PE2, so PE2 will install in
its adjacency. The problem occurs only when both PE1 and PE2 use the same
anycast default gateway IP and MAC addresses (which is also the recommended
option as per draft-ietf-bess-evpn-inter-subnet-forwarding), in which case
the response from the host will be locally consumed by PE1.

Regards,
Muthu

On Mon, Apr 19, 2021 at 11:36 PM  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-krattiger-evpn-modes-interop-03 [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 will
> not  progress without answers from all of 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 4th May 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1]  https://datatracker.ietf.org/doc/draft-krattiger-evpn-modes-interop/
>
>
> ___
> 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] RFC 8584: EVPN DF Election - Originating Router's IP Address of different address family

[Muthu Arul Mozhi Perumal]

Hi Satya,

Please see inline..

On Wed, Feb 10, 2021 at 8:37 AM Satya Mohanty (satyamoh) 
wrote:

> Hi Tulasi and Muthu,
>
>
>
> Yes, the numeric value here refers to the 4byte or 16byte unsigned value
> representation of the IP address field.
>
> Maybe in the 7432-bis this can be stated explicitly.
>

Agree, this is important to clarify in 7432-bis and simple to fix in
implementations that don't compare IPv4 and IPv6 addresses this way for
default DF election algo..


>
>
> We did envision this possibility in RFC 8584 (the HRW hash already takes
> care of the fact that the IP address could be either IPV4 or IPV6).
>
>
>
> However, with respect to deployment do you have a case in mind of this
> “mixed v4/v6” that will necessitate such a tie-break?
>
> I mean one of the MH PEs has an ipv4 originator address and the other a v6
> originator address.
>

Yes, in a dual-stack environment, there could be multihomed PEs running (1)
BGP over IP4 w/ IPv4 NH, (2) BGP over IPv6 w/ IPv4 NH, (3) BGP over IPv6 w/
IPv6 NH, say connected thru' an RR in control plane, and all part of the
same ES group. In this case, the Originating Router's IP address in the ES
route could be an IPv4 or IPv6 address (implementation specific)..

Regards,
Muthu


>
>
> Thanks,
>
> --Satya
>
>
>
>
>
> *From: *BESS  on behalf of TULASI RAM REDDY <
> tulasiramire...@gmail.com>
> *Date: *Friday, February 5, 2021 at 5:17 AM
> *To: *Muthu Arul Mozhi Perumal 
> *Cc: *"bess@ietf.org" 
> *Subject: *Re: [bess] RFC 8584: EVPN DF Election - Originating Router's
> IP Address of different address family
>
>
>
> Thanks Muthu.
>
> Shouldn't numeric value here mean simply the 4byte or 16 byte unsigned
> value representation of the IP address field?
>
> Thinking loudly on how to interpret numeric value  and the limitations
> here. Any comments?
>
>
>
> each PE builds an ordered list of the IP
>
> addresses of all the PE nodes connected to the Ethernet segment
>
> (including itself), in *increasing numeric value*
>
>
>
> Thanks,
>
> Tulasi.
>
> On Fri, Feb 5, 2021 at 3:15 PM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
> Hi Tulasi,
>
>
>
> I think the problem is, there is no standard way to numerically compare
> IPv4 with IPv6 addresses to form an ordered list. So, all the PEs
> multihomed to an ES may not always arrive at the same DF (or BFD in the
> case of single-active L-LINE service) with the default DF election algo.
> This is problematic (and may cause traffic loops). Hence, the default DF
> election algo works only when all PEs multihomed to an ES have Originating
> Router's IP Address of the same AF..
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Thu, Feb 4, 2021 at 7:58 PM TULASI RAM REDDY 
> wrote:
>
> Hi All,
>
>
>
> As mentioned in the Problem Statement of RFC8584 Sec 1.3, Default DF
> algorithm is expected to have
>
> all multihomed PEs to have Originating IP of the same address family.
>
> Do we see any interop issue if the different address families are
> considered, i.e. ordering in
>
> ascending order based on numerical value in Originating IP here? For IPv4
> read 4 octets as unsigned integer
>
> and IPv6 is considered as 16 octet unsigned integer.
>
>
> 1.3 <https://tools.ietf.org/html/rfc8584#section-1.3>.  Problem Statement
>
> Default DF election algorithm assumes
>
> that all the PEs who are multihomed to the same ES (and interested in
>
> the DF election by exchanging EVPN routes) use an Originating
>
> Router's IP address [RFC7432 <https://tools.ietf.org/html/rfc7432>] of the 
> same family.
>
>
>
> Thanks,
>
> TULASI RAMI REDDY N
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>
>
> --
>
> TULASI RAMI REDDY N
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP Address of different address family

[Muthu Arul Mozhi Perumal]

Hi Tulasi,

I think the problem is, there is no standard way to numerically compare
IPv4 with IPv6 addresses to form an ordered list. So, all the PEs
multihomed to an ES may not always arrive at the same DF (or BFD in the
case of single-active L-LINE service) with the default DF election algo.
This is problematic (and may cause traffic loops). Hence, the default DF
election algo works only when all PEs multihomed to an ES have Originating
Router's IP Address of the same AF..

Regards,
Muthu

On Thu, Feb 4, 2021 at 7:58 PM TULASI RAM REDDY 
wrote:

> Hi All,
>
> As mentioned in the Problem Statement of RFC8584 Sec 1.3, Default DF
> algorithm is expected to have
> all multihomed PEs to have Originating IP of the same address family.
> Do we see any interop issue if the different address families are
> considered, i.e. ordering in
> ascending order based on numerical value in Originating IP here? For IPv4
> read 4 octets as unsigned integer
> and IPv6 is considered as 16 octet unsigned integer.
>
> 1.3 .  Problem Statement
>
> Default DF election algorithm assumes
> that all the PEs who are multihomed to the same ES (and interested in
> the DF election by exchanging EVPN routes) use an Originating
> Router's IP address [RFC7432 ] of the 
> same family.
>
>
> Thanks,
> TULASI RAMI REDDY N
> ___
> 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] [Idr] Type 1 RD for Pure IPv6 network -- EVPN

[Muthu Arul Mozhi Perumal]

Not sure, it was just a question..will let Gyan comment if there are
devices out there that don't support RFC6286..

Regards,
Muthu

On Wed, Feb 3, 2021 at 11:21 AM Jakob Heitz (jheitz) 
wrote:

> Why preclude RFC 6286 ?
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr  *On Behalf Of * Muthu Arul Mozhi
> Perumal
> *Sent:* Tuesday, February 2, 2021 9:21 PM
> *To:* Gyan Mishra 
> *Cc:* TULASI RAM REDDY ; bess@ietf.org;
> i...@ietf.org
> *Subject:* Re: [Idr] [bess] Type 1 RD for Pure IPv6 network -- EVPN
>
>
>
> Hi Gyan,
>
>
>
> Please see inline..
>
> Regards,
>
> Muthu
>
>
>
> On Sat, Jan 30, 2021 at 3:26 AM Gyan Mishra  wrote:
>
> Muthu
>
>
>
> How does RFa. 6286 AS wide BGP identifier change the BGP path selection
> process when all attributes are equal and ‘bestpath compare-routerid” is
> uses so the valid/best path is deterministic and oldest versus newest
> default.
>
> The AS wide BGP identifier shouldn't change the BGP path selection process
> in this case, since you compare by converting them to host byte order and
> treating them as 4-octet unsigned integers as per RFC4271.
>
>
>
>
>
>
>
> I believe the BGP Identifier just as with OSPF or ISIS does not have to be
> routable, so in an IPv6 only network precluding RFC 6286 I believe could
> you still use a 4 octet IP address as the router-id.
>
>
>
> Right. However, if we preclude RFC6286, then the BGP identifier needs to
> be a valid unicast host IPv4 address (for e.g. can't be a multicast
> address):
>
>
>
> 
>
>Syntactic correctness means that the BGP Identifier field represents
>a valid unicast IP host address.
>
> 
>
>
>
>
>
>
>
> This question comes up a lot these days as operations migrate to some
> flavor of IPv6 only core MPLS LDPv6, SR-MPLSv6, SRv6.
>
>
>
>
>
> Thanks
>
>
>
> Gyan
>
> On Wed, Jan 27, 2021 at 5:45 AM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
> Hi Tulasi,
>
>
> In pure IPv6 networks, I think using the BGP identifier in place of the IP
> address part in the type 1 RD should suffice for all practical purposes.
> The only catch is, if it is an AS-wide unique BGP identifier [RFC6286],
> then it is not an IP address 'per se'. But, I think it makes no difference
> from an interoperability standpoint..
>
> Perhaps, in line with RFC6286, we should redefine the IP address part of
> the type 1 RD as just a 4-octet, unsigned, non-zero integer..
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Jan 22, 2021 at 11:31 AM TULASI RAM REDDY <
> tulasiramire...@gmail.com> wrote:
>
> Hi All,
>
>
>
> In a pure IPv6 network, how do one expect to construct the Type 1 RD.
>
> As per EVPN RFC 7432 for EAD per ES, it should be Type 1 RD, but if the
> loopback address is only IPv6 then what is the expectation here?
>
> Should we use BGP router ID(32bit) here?
>
>
>
> From RFC7432: EVPN
> 8.2.1 <https://tools.ietf.org/html/rfc7432#section-8.2.1>.  Constructing
> Ethernet A-D per Ethernet Segment Route
>
>The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364 
> <https://tools.ietf.org/html/rfc4364>].  The
>
>*value field comprises an IP address of the PE (typically, the*
>
> *   loopback address)* followed by a number unique to the PE.
>
>
>
> Thanks,
>
> TULASI RAMI REDDY N
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] Type 1 RD for Pure IPv6 network -- EVPN

[Muthu Arul Mozhi Perumal]

Hi Gyan,

Please see inline..
Regards,
Muthu

On Sat, Jan 30, 2021 at 3:26 AM Gyan Mishra  wrote:

> Muthu
>
> How does RFa. 6286 AS wide BGP identifier change the BGP path selection
> process when all attributes are equal and ‘bestpath compare-routerid” is
> uses so the valid/best path is deterministic and oldest versus newest
> default.
>
The AS wide BGP identifier shouldn't change the BGP path selection process
in this case, since you compare by converting them to host byte order and
treating them as 4-octet unsigned integers as per RFC4271.


>
>
> I believe the BGP Identifier just as with OSPF or ISIS does not have to be
> routable, so in an IPv6 only network precluding RFC 6286 I believe could
> you still use a 4 octet IP address as the router-id.
>

Right. However, if we preclude RFC6286, then the BGP identifier needs to be
a valid unicast host IPv4 address (for e.g. can't be a multicast address):


   Syntactic correctness means that the BGP Identifier field represents
   a valid unicast IP host address.



>
>
> This question comes up a lot these days as operations migrate to some
> flavor of IPv6 only core MPLS LDPv6, SR-MPLSv6, SRv6.
>
>
> Thanks
>
> Gyan
> On Wed, Jan 27, 2021 at 5:45 AM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
>> Hi Tulasi,
>>
>> In pure IPv6 networks, I think using the BGP identifier in place of the
>> IP address part in the type 1 RD should suffice for all practical purposes.
>> The only catch is, if it is an AS-wide unique BGP identifier [RFC6286],
>> then it is not an IP address 'per se'. But, I think it makes no difference
>> from an interoperability standpoint..
>>
>> Perhaps, in line with RFC6286, we should redefine the IP address part of
>> the type 1 RD as just a 4-octet, unsigned, non-zero integer..
>>
>> Regards,
>> Muthu
>>
>> On Fri, Jan 22, 2021 at 11:31 AM TULASI RAM REDDY <
>> tulasiramire...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> In a pure IPv6 network, how do one expect to construct the Type 1 RD.
>>> As per EVPN RFC 7432 for EAD per ES, it should be Type 1 RD, but if the
>>> loopback address is only IPv6 then what is the expectation here?
>>> Should we use BGP router ID(32bit) here?
>>>
>>> From RFC7432: EVPN
>>>
>>> 8.2.1 <https://tools.ietf.org/html/rfc7432#section-8.2.1>.  Constructing 
>>> Ethernet A-D per Ethernet Segment Route
>>>
>>>The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364 
>>> <https://tools.ietf.org/html/rfc4364>].  The
>>>*value field comprises an IP address of the PE (typically, the
>>>loopback address)* followed by a number unique to the PE.
>>>
>>>
>>> Thanks,
>>> TULASI RAMI REDDY N
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>> ___
>> Idr mailing list
>> i...@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Type 1 RD for Pure IPv6 network -- EVPN

[Muthu Arul Mozhi Perumal]

Hi Tulasi,

In pure IPv6 networks, I think using the BGP identifier in place of the IP
address part in the type 1 RD should suffice for all practical purposes.
The only catch is, if it is an AS-wide unique BGP identifier [RFC6286],
then it is not an IP address 'per se'. But, I think it makes no difference
from an interoperability standpoint..

Perhaps, in line with RFC6286, we should redefine the IP address part of
the type 1 RD as just a 4-octet, unsigned, non-zero integer..

Regards,
Muthu

On Fri, Jan 22, 2021 at 11:31 AM TULASI RAM REDDY 
wrote:

> Hi All,
>
> In a pure IPv6 network, how do one expect to construct the Type 1 RD.
> As per EVPN RFC 7432 for EAD per ES, it should be Type 1 RD, but if the
> loopback address is only IPv6 then what is the expectation here?
> Should we use BGP router ID(32bit) here?
>
> From RFC7432: EVPN
>
> 8.2.1 .  Constructing 
> Ethernet A-D per Ethernet Segment Route
>
>The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364 
> ].  The
>*value field comprises an IP address of the PE (typically, the
>loopback address)* followed by a number unique to the PE.
>
>
> Thanks,
> TULASI RAMI REDDY N
> ___
> 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] Question on ARP probe in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Please see inline..

On Fri, May 3, 2019 at 12:02 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> You only need the IP-VRF RT in case of the IP is included in the MAC/IP
> route _*and*_ you are in symmetric mode, since you need to install the IP
> in the route-table.
>

If we follow the argument that there is only one IP-VRF per BD which you
can identify based on the RT for the MAC-VRF and Ethernet  tag, you don't
need the RT for the IP-VRF even if the MAC/IP route includes the IP and you
are in symmetric mode, right?


> The mobility section is done for both symmetric and asymmetric modes, and
> also, in particular, that case you allude to, there is only a MAC in the
> route that the source NVE receives. So you cannot guarantee the source NVE
> will receive an RT for the IP-VRF.
>

Agree. But, neither section 4.2 nor anywhere else
in draft-ietf-bess-evpn-inter-subnet-forwarding we describe how the source
NVE deduces the IP-VRF when the MAC/IP route has only the MAC address and
MAC-VRF RT.

Regards,
Muthu


>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Friday, May 3, 2019 at 7:39 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"bess@ietf.org" 
> *Subject: *Re: [bess] Question on ARP probe in
> draft-ietf-bess-evpn-inter-subnet-forwarding
>
>
>
> Hi Jorge,
>
>
>
> Thanks for your response. Please see inline..
>
>
>
> On Tue, Apr 30, 2019 at 8:43 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> Muthu,
>
>
>
> The source NVE identifies the MAC-VRF/BD out of the RT/eth-tag. The
> assumption is that the BD is only attached to one IP-VRF, hence you know
> what ARP table to look up.
>
>
>
> If this is the case, why include the RT for the IP-VRF at all in route
> type-2 advertisements?
>
>
>
> Regards,
>
> Muthu
>
>
>
> My two cents.
>
>
>
> Jorge
>
>
>
> *From: *BESS  on behalf of Muthu Arul Mozhi
> Perumal 
> *Date: *Tuesday, April 30, 2019 at 4:39 AM
> *To: *"bess@ietf.org" 
> *Subject: *[bess] Question on ARP probe in
> draft-ietf-bess-evpn-inter-subnet-forwarding
>
>
>
> Hi Everyone,
>
>
>
> draft-ietf-bess-evpn-inter-subnet-forwarding describes the mobility
> procedure to be followed when a TS moves from a source NVE to a target NVE
> and starts sending data traffic without first initiating an ARP request. It
> says the following in section 4.2:
>
>
>
> 
>
>- The source NVE upon receiving this MAC/IP advertisement, realizes
>
>that the MAC has moved to the new NVE. It updates its MAC-VRF table
>
>accordingly by updating the adjacency information for that MAC
>
>address to point to the target NVE and withdraws its EVPN MAC/IP
>
>route that has only the MAC address (if it has advertised such route
>
>previously). Furthermore, *it searches its ARP table for this MAC and*
>
>*sends an ARP probe for this  pair*. The ARP request message is
>
>sent both locally to all attached TSes in that subnet as well as it
>
>is sent to other NVEs participating in that subnet including the
>
>target NVE.
>
> 
>
>
>
> The question I have is, the MAC/IP Advertisement route the source NVE
> receives from the target NVE in the above case has only the MAC address of
> the TS and the RT corresponding to the MAC-VRF. How can the source NVE
> deduce the IP-VRF to search the corresponding ARP table and send an ARP
> probe?
>
>
>
> Regards,
>
> Muthu
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Question on ARP probe in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Hi Jorge,

Thanks for your response. Please see inline..

On Tue, Apr 30, 2019 at 8:43 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Muthu,
>
>
>
> The source NVE identifies the MAC-VRF/BD out of the RT/eth-tag. The
> assumption is that the BD is only attached to one IP-VRF, hence you know
> what ARP table to look up.
>

If this is the case, why include the RT for the IP-VRF at all in route
type-2 advertisements?

Regards,
Muthu

>
>
> My two cents.
>
>
>
> Jorge
>
>
>
> *From: *BESS  on behalf of Muthu Arul Mozhi
> Perumal 
> *Date: *Tuesday, April 30, 2019 at 4:39 AM
> *To: *"bess@ietf.org" 
> *Subject: *[bess] Question on ARP probe in
> draft-ietf-bess-evpn-inter-subnet-forwarding
>
>
>
> Hi Everyone,
>
>
>
> draft-ietf-bess-evpn-inter-subnet-forwarding describes the mobility
> procedure to be followed when a TS moves from a source NVE to a target NVE
> and starts sending data traffic without first initiating an ARP request. It
> says the following in section 4.2:
>
>
>
> 
>
>- The source NVE upon receiving this MAC/IP advertisement, realizes
>
>that the MAC has moved to the new NVE. It updates its MAC-VRF table
>
>accordingly by updating the adjacency information for that MAC
>
>address to point to the target NVE and withdraws its EVPN MAC/IP
>
>route that has only the MAC address (if it has advertised such route
>
>previously). Furthermore, *it searches its ARP table for this MAC and*
>
>*sends an ARP probe for this  pair*. The ARP request message is
>
>sent both locally to all attached TSes in that subnet as well as it
>
>is sent to other NVEs participating in that subnet including the
>
>target NVE.
>
> 
>
>
>
> The question I have is, the MAC/IP Advertisement route the source NVE
> receives from the target NVE in the above case has only the MAC address of
> the TS and the RT corresponding to the MAC-VRF. How can the source NVE
> deduce the IP-VRF to search the corresponding ARP table and send an ARP
> probe?
>
>
>
> Regards,
>
> Muthu
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Question on ARP probe in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Hi Everyone,

draft-ietf-bess-evpn-inter-subnet-forwarding describes the mobility
procedure to be followed when a TS moves from a source NVE to a target NVE
and starts sending data traffic without first initiating an ARP request. It
says the following in section 4.2:


   - The source NVE upon receiving this MAC/IP advertisement, realizes
   that the MAC has moved to the new NVE. It updates its MAC-VRF table
   accordingly by updating the adjacency information for that MAC
   address to point to the target NVE and withdraws its EVPN MAC/IP
   route that has only the MAC address (if it has advertised such route
   previously). Furthermore, *it searches its ARP table for this MAC and*
   *sends an ARP probe for this  pair*. The ARP request message is
   sent both locally to all attached TSes in that subnet as well as it
   is sent to other NVEs participating in that subnet including the
   target NVE.


The question I have is, the MAC/IP Advertisement route the source NVE
receives from the target NVE in the above case has only the MAC address of
the TS and the RT corresponding to the MAC-VRF. How can the source NVE
deduce the IP-VRF to search the corresponding ARP table and send an ARP
probe?

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

Re: [bess] EVPN Multihoming and Symmetric IRB

[Muthu Arul Mozhi Perumal]

Hi Bob,

Thanks for your response. Please see inline..

On Thu, Apr 25, 2019 at 6:28 AM  wrote:

> Hi Muthu and everyone else,
>
>
> The IP Aliasing in Symmetric IRB is described in 
> draft-sajassi-bess-evpn-ip-aliasing-00
> .
>
> It works well for each local host learned on the IRB interface.
>
Glad to know that my understand that fast convergence, aliasing and backup
path as described in RFC 7432 is applicable only for host MAC addresses and
not for their IP addresses is correct :) I think it is important to capture
this implication for symmetric IRB
in draft-ietf-bess-evpn-inter-subnet-forwarding and probably add a
reference to draft-sajassi-bess-evpn-ip-aliasing to indicate how those
functionalities can be realized in the symmetric IRB case.

On a different note, when IP aliasing is used, I think it slightly modifies
the definition of symmetric IRB because the egress PE is no longer doing a
lookup in the IP-VRF, rather forwarding the packet on the ES after doing a
LFIB lookup. This should perhaps be captured in
draft-sajassi-bess-evpn-ip-aliasing.

>
> I think when the IRB interface itself is configured with an anycast
> Gateway IP-address for its corresponding subnet,
>
> the IP address of the IRB interface itself doesn't have an explicit ESI to
> be announced together with its own MAC/IP address in current documents,
>
Why do we need a non-zero ES for the anycast gateway IP address? My
understanding is that you include the gateway IP address in the MAC/IP
advertisement route for MAC address aliasing so that the receiver can check
if the received IP address matches with the locally configured anycast
gateway IP address. Does it serve any other purpose?

Regards,
Muthu

> Can we use an vESI for IRB interface itself or its corresponding MAC-VRF
> (which is similar ot the I-ESI concept)?
>
> This issue exists in both symmetric IRB and asymmetric IRB.
>
>
> Thanks
>
> Bob
>
>
> On Wed, 24 Apr 2019 09:57:51 +0530
>
> Muthu Arul Mozhi Perumal  wrote:
>
>
> > Hi Everyone,
>
> >
>
> > draft-ietf-bess-evpn-inter-subnet-forwarding does not explicitly describe
>
> > the implications of EVPN multihoming on IRB. It seems to assume that the
>
> > IRB procedures can be easily extrapolated to multihoming following RFC
> 7432
>
> > and it says so at least for the mobility procedures described in section
> 4.
>
> >
>
> > However, I think there are key implications of multihoming for symmetric
>
> > IRB.
>
> >
>
> > Fast Convergence:
>
> > Section 8.2 of RFC 7432 says the following:
>
> > 
>
> >Upon a failure in connectivity to the attached segment, the PE
>
> >withdraws the corresponding set of Ethernet A-D per ES routes.  This
>
> >triggers all PEs that receive the withdrawal to update their next-hop
>
> >adjacencies for all *MAC addresses* associated with the Ethernet
>
> >segment in question.  If no other PE had advertised an Ethernet A-D
>
> >route for the same segment, then the PE that received the withdrawal
>
> >simply invalidates the *MAC entries *for that segment.  Otherwise, the
>
> >PE updates its next-hop adjacencies accordingly.
>
> > 
>
> >
>
> > Clearly, it describes fast convergence only for the MAC addresses of TSs
>
> > (and not for their IP addresses). In symmetric IRB, the ingress PE
> performs
>
> > a route lookup for the destination TS prefix in IP-VRF and forwards the
>
> > packet to the egress PE. Hence, the above fast convergence is not
>
> > applicable. It however is applicable for asymmetric IRB where the
>
> > destination subnet is configured in the ingress PE and it performs a
> lookup
>
> > in the BT corresponding to the destination subnet and forwards the frame.
>
> >
>
> > Aliasing and Backup Path:
>
> > With symmetric IRB, the ingress PE cannot use alias label (i.e. label
>
> > advertised in AD per EVI route) to load balance traffic sent to egress
> PEs
>
> > multihomed to the same CE, since the egress PE needs to first perform a
>
> > route lookup for the destination prefix in the IP-VRF to forward the
>
> > packet. The ingress PE instead needs to rely on multipath techniques
>
> > applicable to L3VPN (such as BGP multipath).
>
> >
>
> > Now, coming to the backup path, section 8.4 of RFC 7432 says the
> following:
>
> > 
>
> >The backup path is a closely related function, but it is used in
>
> >Single-Active redundancy mode.  In this case, a PE also advertises
>
> >that it has reachability to a given EVI/ES using the same combinati

[bess] EVPN Multihoming and Symmetric IRB

[Muthu Arul Mozhi Perumal]

Hi Everyone,

draft-ietf-bess-evpn-inter-subnet-forwarding does not explicitly describe
the implications of EVPN multihoming on IRB. It seems to assume that the
IRB procedures can be easily extrapolated to multihoming following RFC 7432
and it says so at least for the mobility procedures described in section 4.

However, I think there are key implications of multihoming for symmetric
IRB.

Fast Convergence:
Section 8.2 of RFC 7432 says the following:

   Upon a failure in connectivity to the attached segment, the PE
   withdraws the corresponding set of Ethernet A-D per ES routes.  This
   triggers all PEs that receive the withdrawal to update their next-hop
   adjacencies for all *MAC addresses* associated with the Ethernet
   segment in question.  If no other PE had advertised an Ethernet A-D
   route for the same segment, then the PE that received the withdrawal
   simply invalidates the *MAC entries *for that segment.  Otherwise, the
   PE updates its next-hop adjacencies accordingly.


Clearly, it describes fast convergence only for the MAC addresses of TSs
(and not for their IP addresses). In symmetric IRB, the ingress PE performs
a route lookup for the destination TS prefix in IP-VRF and forwards the
packet to the egress PE. Hence, the above fast convergence is not
applicable. It however is applicable for asymmetric IRB where the
destination subnet is configured in the ingress PE and it performs a lookup
in the BT corresponding to the destination subnet and forwards the frame.

Aliasing and Backup Path:
With symmetric IRB, the ingress PE cannot use alias label (i.e. label
advertised in AD per EVI route) to load balance traffic sent to egress PEs
multihomed to the same CE, since the egress PE needs to first perform a
route lookup for the destination prefix in the IP-VRF to forward the
packet. The ingress PE instead needs to rely on multipath techniques
applicable to L3VPN (such as BGP multipath).

Now, coming to the backup path, section 8.4 of RFC 7432 says the following:

   The backup path is a closely related function, but it is used in
   Single-Active redundancy mode.  In this case, a PE also advertises
   that it has reachability to a given EVI/ES using the same combination
   of Ethernet A-D per EVI route and Ethernet A-D per ES route as
   discussed above, but with the "Single-Active" bit in the flags of the
   ESI Label extended community set to 1.  A remote PE that receives a
   MAC/IP Advertisement route with a non-reserved ESI SHOULD consider
   the *advertised MAC address* to be reachable via any PE that has
   advertised this combination of Ethernet A-D routes, and it SHOULD
   install a backup path for that MAC address.


Clearly, it describes the backup path only for the MAC address of the TS
(and not for their IP address). Hence, it is not applicable to symmetric
IRB. It however is applicable to asymmetric IRB.

Is my understanding correct? Shouldn't the implications of multihoming on
symmetric IRB be explicitly captured
in draft-ietf-bess-evpn-inter-subnet-forwarding?

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

[bess] ​Question on EVPN Default Gateway MAC Address Aliasing

[Muthu Arul Mozhi Perumal]

Section 10.1 of RFC7432 describes the MAC address aliasing procedure. It
describes how a PE that acts as a default gateway advertises the default
gateway MAC address using the MAC/IP route together with the Default
Gateway EC. It says that:

   - The IP Address field of the MAC/IP route is set to the default gateway
   IP address.
   - The ESI field is set to 0.
   - MPLS label is set to a downstream assigned label.

It however does not say anything about MPLS Label2 (neither
does draft-ietf-bess-evpn-inter-subnet-forwarding). I think MPLS Label2
does not serve any purpose here since the receiver is not expected to
import the IP address into its IP-VRF as it is the default gateway
anycast IP address.

However, I think the MAC/IP route should be advertised with both the
MAC-VRF and IP-VRF RTs to enable the receiving PE to check its configured
default gateway IP address against the one received in the MAC/IP route and
log an should there be a discrepancy.

Is my understanding correct?

Does this clarification belong to RFC7432bis or
bess-evpn-inter-subnet-forwarding?

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

Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

[Muthu Arul Mozhi Perumal]

Hi Jorge,

Okay, thanks for the clarification..

Regards,
Muthu

On Tue, Apr 9, 2019 at 11:17 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Hi,
>
>
>
> I think the definition of Ethernet Tag in the framework draft should be
> clear enough.
>
> There are implementations using configured IDs.
>
> Jorge
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Tuesday, April 9, 2019 at 2:54 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *Jaikumar Somasundaram , "
> bess@ietf.org" , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *Re: [bess] DF election rule in EVPN MH, for untagged interface
> - reg
>
>
>
> Hi Jorge,
>
>
>
> For EVPN VPWS, I understand that service instance identifies are used as
> Ethernet Tags in the DF election. However, for EVPN VPLS is it common to
> configure anything other than the VLAN ID (VID) as the Ethernet Tag? Do we
> have vendor implementations providing such an Ethernet Tag configuration
> different from the VID for EVPN VPLS?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Apr 5, 2019 at 9:49 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> The Ethernet Tag that you use for DF Election does not even need to match
> what you have in the data path.
>
> Note that the definition says even “configured IDs”.
>
>
>
> As long as you use the same ID for the BD on all the PEs attached to the
> ES, you are fine.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Friday, April 5, 2019 at 5:10 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *Jaikumar Somasundaram , "
> bess@ietf.org" , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *Re: [bess] DF election rule in EVPN MH, for untagged interface
> - reg
>
>
>
> Thanks, Jorge. It is clear that the Ethernet Tag needs to be different
> from 0 for the purpose of DF election..
>
>
>
> One of the options a provider has for supporting untagged frames in EVPN
> VPLS multihoming in VID translation...a rule to match untagged frames and
> impose a VID at the ingress and another rule to match that VID and dispose
> it at the egress.
>
>
>
> Are there any other options that can interop well?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Apr 5, 2019 at 11:11 AM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> Hi,
>
>
>
> I think you should check out
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09
>
>
>
> This draft updates RFC7432 in certain aspects of the DF Election, and it
> is already at the RFC editor.
>
>
>
> Check out the use of Ethernet Tag in the document.
>
>
>
>o Ethernet Tag - used to represent a Broadcast Domain that is
>
>  configured on a given ES for the purpose of DF election. Note that
>
>  any of the following may be used to represent a Broadcast Domain:
>
>  VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
>
>  Identifiers), normalized VID, I-SIDs (Service Instance
>
>  Identifiers), etc., as long as the representation of the broadcast
>
>  domains is configured consistently across the multi-homed PEs
>
>  attached to that ES. The Ethernet Tag value MUST be different from
>
>  zero.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *BESS  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Friday, April 5, 2019 at 6:15 AM
> *To: *"bess@ietf.org" 
> *Cc: *P Muthu Arul Mozhi 
> *Subject: *[bess] DF election rule in EVPN MH, for untagged interface -
> reg
>
>
>
> Hi All,
>
>
>
> RFC7432, section 8.5, talks about DF election algorithm (service carving
> algorithm)
>
> only for  for VLAN-based service or  for 
> VLAN-(aware)
>
> bundle service.
>
>
>
> But there wont be any vlan id for untagged interface and so I wonder
>
> how the service carving algorithm can be applied to elect the DF.
>
> Also, should I use the lower VLAN ID even in the case of VLAN-bundle
>
> service, for electing the DF?
>
>
>
> Could some one help me to understand this please?
>
>
>
> =
> 8.5 <https://tools.ietf.org/html/rfc7432#section-8.5>.  Designated
> Forwarder Election
>
> …
>
>The default procedure for DF election at the granularity of 
>VL

Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

[Muthu Arul Mozhi Perumal]

Hi Jorge,

For EVPN VPWS, I understand that service instance identifies are used as
Ethernet Tags in the DF election. However, for EVPN VPLS is it common to
configure anything other than the VLAN ID (VID) as the Ethernet Tag? Do we
have vendor implementations providing such an Ethernet Tag configuration
different from the VID for EVPN VPLS?

Regards,
Muthu

On Fri, Apr 5, 2019 at 9:49 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> The Ethernet Tag that you use for DF Election does not even need to match
> what you have in the data path.
>
> Note that the definition says even “configured IDs”.
>
>
>
> As long as you use the same ID for the BD on all the PEs attached to the
> ES, you are fine.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Friday, April 5, 2019 at 5:10 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *Jaikumar Somasundaram , "
> bess@ietf.org" , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *Re: [bess] DF election rule in EVPN MH, for untagged interface
> - reg
>
>
>
> Thanks, Jorge. It is clear that the Ethernet Tag needs to be different
> from 0 for the purpose of DF election..
>
>
>
> One of the options a provider has for supporting untagged frames in EVPN
> VPLS multihoming in VID translation...a rule to match untagged frames and
> impose a VID at the ingress and another rule to match that VID and dispose
> it at the egress.
>
>
>
> Are there any other options that can interop well?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Apr 5, 2019 at 11:11 AM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> Hi,
>
>
>
> I think you should check out
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09
>
>
>
> This draft updates RFC7432 in certain aspects of the DF Election, and it
> is already at the RFC editor.
>
>
>
> Check out the use of Ethernet Tag in the document.
>
>
>
>o Ethernet Tag - used to represent a Broadcast Domain that is
>
>  configured on a given ES for the purpose of DF election. Note that
>
>  any of the following may be used to represent a Broadcast Domain:
>
>  VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
>
>  Identifiers), normalized VID, I-SIDs (Service Instance
>
>  Identifiers), etc., as long as the representation of the broadcast
>
>  domains is configured consistently across the multi-homed PEs
>
>  attached to that ES. The Ethernet Tag value MUST be different from
>
>  zero.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *BESS  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Friday, April 5, 2019 at 6:15 AM
> *To: *"bess@ietf.org" 
> *Cc: *P Muthu Arul Mozhi 
> *Subject: *[bess] DF election rule in EVPN MH, for untagged interface -
> reg
>
>
>
> Hi All,
>
>
>
> RFC7432, section 8.5, talks about DF election algorithm (service carving
> algorithm)
>
> only for  for VLAN-based service or  for 
> VLAN-(aware)
>
> bundle service.
>
>
>
> But there wont be any vlan id for untagged interface and so I wonder
>
> how the service carving algorithm can be applied to elect the DF.
>
> Also, should I use the lower VLAN ID even in the case of VLAN-bundle
>
> service, for electing the DF?
>
>
>
> Could some one help me to understand this please?
>
>
>
> =
> 8.5 <https://tools.ietf.org/html/rfc7432#section-8.5>.  Designated
> Forwarder Election
>
> …
>
>The default procedure for DF election at the granularity of 
>VLAN> for VLAN-based service or  for VLAN-(aware)
>
>bundle service is referred to as "service carving".
>
> …
>
>   Assuming a redundancy group of N PE nodes, for VLAN-based service,
>
>   the PE with ordinal i is the DF for an  when (V mod N)
>
>   = i.  In the case of VLAN-(aware) bundle service, then the
>
>   numerically lowest VLAN value in that bundle on that ES MUST be
>
>   used in the modulo function.
>
> …
>
> ===
>
>
>
> Thanks & Regards
>
> Jaikumar S
>
>
>
> ___
> 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] DF election rule in EVPN MH, for untagged interface - reg

[Muthu Arul Mozhi Perumal]

Thanks, Jorge. It is clear that the Ethernet Tag needs to be different from
0 for the purpose of DF election..

One of the options a provider has for supporting untagged frames in EVPN
VPLS multihoming in VID translation...a rule to match untagged frames and
impose a VID at the ingress and another rule to match that VID and dispose
it at the egress.

Are there any other options that can interop well?

Regards,
Muthu

On Fri, Apr 5, 2019 at 11:11 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Hi,
>
>
>
> I think you should check out
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09
>
>
>
> This draft updates RFC7432 in certain aspects of the DF Election, and it
> is already at the RFC editor.
>
>
>
> Check out the use of Ethernet Tag in the document.
>
>
>
>o Ethernet Tag - used to represent a Broadcast Domain that is
>
>  configured on a given ES for the purpose of DF election. Note that
>
>  any of the following may be used to represent a Broadcast Domain:
>
>  VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
>
>  Identifiers), normalized VID, I-SIDs (Service Instance
>
>  Identifiers), etc., as long as the representation of the broadcast
>
>  domains is configured consistently across the multi-homed PEs
>
>  attached to that ES. The Ethernet Tag value MUST be different from
>
>  zero.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *BESS  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Friday, April 5, 2019 at 6:15 AM
> *To: *"bess@ietf.org" 
> *Cc: *P Muthu Arul Mozhi 
> *Subject: *[bess] DF election rule in EVPN MH, for untagged interface -
> reg
>
>
>
> Hi All,
>
>
>
> RFC7432, section 8.5, talks about DF election algorithm (service carving
> algorithm)
>
> only for  for VLAN-based service or  for 
> VLAN-(aware)
>
> bundle service.
>
>
>
> But there wont be any vlan id for untagged interface and so I wonder
>
> how the service carving algorithm can be applied to elect the DF.
>
> Also, should I use the lower VLAN ID even in the case of VLAN-bundle
>
> service, for electing the DF?
>
>
>
> Could some one help me to understand this please?
>
>
>
> =
> 8.5 .  Designated
> Forwarder Election
>
> …
>
>The default procedure for DF election at the granularity of 
>VLAN> for VLAN-based service or  for VLAN-(aware)
>
>bundle service is referred to as "service carving".
>
> …
>
>   Assuming a redundancy group of N PE nodes, for VLAN-based service,
>
>   the PE with ordinal i is the DF for an  when (V mod N)
>
>   = i.  In the case of VLAN-(aware) bundle service, then the
>
>   numerically lowest VLAN value in that bundle on that ES MUST be
>
>   used in the modulo function.
>
> …
>
> ===
>
>
>
> Thanks & Regards
>
> Jaikumar S
>
>
> ___
> 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] Comment on MAC Mobility Procedure in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Section 4.1 of draft-ietf-bess-evpn-inter-subnet-forwarding describes the
mobility procedure when a host initiates an ARP request upon a move.

It says the following regarding the source NVE:


   Furthermore, it sends an ARP probe locally to
   ensure that the MAC is gone.  If an ARP response is received, the
   source NVE updates its ARP entry for that  and re-advertises
   an EVPN MAC/IP route for that  along with MAC Mobility
   Extended Community with the sequence number incremented by one. The
   source NVE also exercises the MAC duplication detection procedure in
   section 15.1 of [RFC7432].


Here, the source NVE is trying to verify if the TS has actually moved back.
However, initiating an ARP probe looks redundant here since the host would
anyway initiate an ARP request upon a move (which is the assumption in that
section). So, the source NVE will anyway detect that the host has moved
back if it re-learns the MAC/IP locally through the ARP request, right?

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

Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

[Muthu Arul Mozhi Perumal]

Hi Satya,

Thanks for your response..

I see no harm in stating explicitly how the BDF is to be calculated for the
default DF election algorithm.

I however agree that it can't be generalized for all future DF election
algorithms, so it is better described on a per algorithm basis..

Regards,
Muthu

On Thu, Mar 28, 2019 at 12:17 AM Satya Mohanty (satyamoh) <
satya...@cisco.com> wrote:

> Hi Muthu,
>
>
>
> As you mentioned it is straightforward to calculate the BDF in the default
> DF Algorithm by taking the current DF out of reckoning.
>
> It is my personal view that since this is self-evident it need not be
> explicitly stated.
>
> But I will let others decide.
>
>
>
>
>
> Thanks,
>
> --Satya
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Monday, March 25, 2019 at 8:22 AM
> *To: *"Satya Mohanty (satyamoh)" 
> *Cc: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Subject: *Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> Hi Satya,
>
>
>
> draft-ietf-bess-evpn-df-election-framework also does not describe how the
> BDF is to be calculated for the default DF election algo. Am I missing
> something?
>
>
>
> I think my question still holds:
>
> Though it is straightforward to calculate the BDF by eliminating the DF
> from the candidate list, would an implementation calculating the BDF that
> way for the default DF election algo interoperate without any problem?
>
>
>
> Would it be better to update draft-ietf-bess-evpn-df-election-framework on
> how the BDF is to be calculated in general for any DF election algo
> (including the default DF election algo)?
>
> [Satya] IMHO opinion, much as it appears obvious, we cannot say for
> certain that in every future DF algorithm (that may come into existence),
> the BDF computation will always be as simple as taking the current DF (PE)
> out of reckoning and doing the recomputation.
>
>
>
> Regards,
>
> Muthu
>
>
>
> Best,
>
> --Satya
>
>
>
> On Sat, Mar 23, 2019 at 2:46 AM Satya Mohanty (satyamoh) <
> satya...@cisco.com> wrote:
>
> Hi Muthu,
>
>
>
> Yes, the BDF is as per what you have mentioned.
>
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09
> formally defines it.
>
>
>
> Thanks,
>
> --Satya
>
>
>
> *From: *BESS  on behalf of Muthu Arul Mozhi
> Perumal 
> *Date: *Friday, March 22, 2019 at 11:41 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"bess@ietf.org" 
> *Subject: *Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> Thanks, Jorge. Need another clarification. RFC 7432 does not describe how
> to calculate the BDF for the default DF algo. Though it is straightforward
> to calculate the BDF by eliminating the DF from the candidate list, would
> an implementation calculating the BDF that way for the default DF algo
> interoperate without any problem?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Mar 22, 2019 at 11:45 PM Rabadan, Jorge (Nokia - US/Mountain View)
>  wrote:
>
> Hi,
>
>
>
> Well, everyone has to support the default DF Alg, based on RFC7432. So
> that one for sure. And in addition there are others that have been
> implemented. For instance, Pref DF election has been implemented by
> multiple vendors.
>
> Thanks,
>
> Jorge
>
>
> --
>
> *From:* Muthu Arul Mozhi Perumal 
> *Sent:* Friday, March 22, 2019 10:41
> *To:* Rabadan, Jorge (Nokia - US/Mountain View)
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> Hi Jorge,
>
>
>
> I didn't mean using different algorithms for electing the DF and BFD. I am
> just asking which algorithm is most widely implemented/used for electing
> the DF *and* BDF for EVPN VPWS single-active multihoming.
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Mar 22, 2019 at 7:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> The implementations I know use the same DF Alg for DF election _*and*_
> backup DF Election. And I don’t see why you would use something different?
>
> In other words, if you use e.g., Pref based DF Alg, use it for DF and BDF
> elections. Only that the BDF election excludes the DF from the candidate
> list.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From:*BESS  on behalf of Muthu Arul Mozhi Perumal
> 
> *Date: *Friday, March 22, 2019 at 4:23 AM
> *To: *"bess@ietf.org" 
> *Subject: *[bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> While RFC 8214 doesn't recommend any DF election algorithm capable of
> electing the BDF in EVPN VPWS single-active multihoming for deciding the
> backup PE, any feedback on what is(are) the widely implemented/supported DF
> election  algorithm(s) by vendors?
>
>
>
> Regards,
>
> Muthu
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Question on symmetric IRB procedures in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Hi authors, EVPN experts,

Any feedback?

Regards,
Muthu

On Wed, Mar 20, 2019 at 10:19 AM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:

> draft-ietf-bess-evpn-inter-subnet-forwarding says the following in section
> 3.2.2:
>
> 
>If the receiving PE receives this route with both the MAC-VRF and IP-
>VRF route targets but the MAC/IP Advertisement route does not include
>MPLS label2 field and if the receiving PE supports asymmetric IRB
>mode, then the receiving PE installs the MAC address in the
>corresponding MAC-VRF and  association in the ARP table for
>that tenant (identified by the corresponding IP-VRF route target).
> 
>
> Further below it says:
>
> 
>If the receiving PE receives this route with both the MAC-VRF and IP-
>VRF route targets but the MAC/IP Advertisement route does not include
>MPLS label2 field and if the receiving PE does not support either
>asymmetric or symmetric IRB modes, then if it has the corresponding
>MAC-VRF, it only imports the MAC address
> 
>
> How should "does not support either asymmetric or symmetric IRB" be
> interpreted? Should it be interpreted as "supports neither asymmetric nor
> symmetric"? Or should it be interpreted as "does not support one of them"?
>
> If it is the former, then the case where the receiving PE supports only
> symmetric (but not asymmetric) IRB isn't described. It it is the later then
> it includes the case where the receiving PE supports only asymmetric (but
> not symmetric) IRB and what is described in that paragraph conflicts with
> the first paragraph mentioned above.
>
> Regards,
> Muthu
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Question on IRB MAC in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Hi authors, EVPN experts,

Any feedback?

Regards,
Muthu

On Tue, Mar 19, 2019 at 4:00 PM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:

> draft-ietf-bess-evpn-inter-subnet-forwarding describes two ways of
> provisioning the default gateway MAC and IP addresses on the IRB interface
> associated with the corresponding subnet:
>
> 
>1. All the PEs for a given tenant subnet use the same anycast default
>gateway IP and MAC addresses . On each PE, this default gateway IP
>and MAC addresses correspond to the IRB interface connecting the BT
>associated with the tenant's VLAN to the corresponding tenant's IP-
>VRF.
>
>2. Each PE for a given tenant subnet uses the same anycast default
>gateway IP address but its own MAC address. These MAC addresses are
>aliased to the same anycast default gateway IP address through the
>use of the Default Gateway extended community as specified in
>[RFC7432], which is carried in the EVPN MAC/IP Advertisement routes.
> 
>
> Further below it says:
>
> 
>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).
> 
>
> In the above, it says the ARP response or NS will use the anycast MAC
> address. The question is, how is this feasible if the second option of 
> provisioning
> the default gateway MAC and IP addresses on the IRB interface are chosen,
> where each PE for a given tenant subnet uses the same anycast default
> gateway IP address but its own MAC address?
>
> Should it instead say:
>   the request is sent for the anycast IP address of the IRB interface
>associated with the TS's subnet and the reply will use *configured*
>MAC address?
>
> i.e. s/anycast MAC/configured MAC?
>
> Regards,
> Muthu
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

[Muthu Arul Mozhi Perumal]

Hi Satya,

draft-ietf-bess-evpn-df-election-framework also does not describe how the
BDF is to be calculated for the default DF election algo. Am I missing
something?

I think my question still holds:
Though it is straightforward to calculate the BDF by eliminating the DF
from the candidate list, would an implementation calculating the BDF that
way for the default DF election algo interoperate without any problem?

Would it be better to update draft-ietf-bess-evpn-df-election-framework on
how the BDF is to be calculated in general for any DF election algo
(including the default DF election algo)?

Regards,
Muthu

On Sat, Mar 23, 2019 at 2:46 AM Satya Mohanty (satyamoh) 
wrote:

> Hi Muthu,
>
>
>
> Yes, the BDF is as per what you have mentioned.
>
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09
> formally defines it.
>
>
>
> Thanks,
>
> --Satya
>
>
>
> *From: *BESS  on behalf of Muthu Arul Mozhi
> Perumal 
> *Date: *Friday, March 22, 2019 at 11:41 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"bess@ietf.org" 
> *Subject: *Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> Thanks, Jorge. Need another clarification. RFC 7432 does not describe how
> to calculate the BDF for the default DF algo. Though it is
> straightforward to calculate the BDF by eliminating the DF from the
> candidate list, would an implementation calculating the BDF that way for
> the default DF algo interoperate without any problem?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Mar 22, 2019 at 11:45 PM Rabadan, Jorge (Nokia - US/Mountain View)
>  wrote:
>
> Hi,
>
>
>
> Well, everyone has to support the default DF Alg, based on RFC7432. So
> that one for sure. And in addition there are others that have been
> implemented. For instance, Pref DF election has been implemented by
> multiple vendors.
>
> Thanks,
>
> Jorge
>
>
> --
>
> *From:* Muthu Arul Mozhi Perumal 
> *Sent:* Friday, March 22, 2019 10:41
> *To:* Rabadan, Jorge (Nokia - US/Mountain View)
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> Hi Jorge,
>
>
>
> I didn't mean using different algorithms for electing the DF and BFD. I am
> just asking which algorithm is most widely implemented/used for electing
> the DF *and* BDF for EVPN VPWS single-active multihoming.
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Mar 22, 2019 at 7:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> The implementations I know use the same DF Alg for DF election _*and*_
> backup DF Election. And I don’t see why you would use something different?
>
> In other words, if you use e.g., Pref based DF Alg, use it for DF and BDF
> elections. Only that the BDF election excludes the DF from the candidate
> list.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From:*BESS  on behalf of Muthu Arul Mozhi Perumal
> 
> *Date: *Friday, March 22, 2019 at 4:23 AM
> *To: *"bess@ietf.org" 
> *Subject: *[bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> While RFC 8214 doesn't recommend any DF election algorithm capable of
> electing the BDF in EVPN VPWS single-active multihoming for deciding the
> backup PE, any feedback on what is(are) the widely implemented/supported DF
> election  algorithm(s) by vendors?
>
>
>
> Regards,
>
> Muthu
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

[Muthu Arul Mozhi Perumal]

Thanks, Jorge. Need another clarification. RFC 7432 does not describe how
to calculate the BDF for the default DF algo. Though it is straightforward
to calculate the BDF by eliminating the DF from the candidate list, would
an implementation calculating the BDF that way for the default DF algo
interoperate without any problem?

Regards,
Muthu

On Fri, Mar 22, 2019 at 11:45 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Hi,
>
> Well, everyone has to support the default DF Alg, based on RFC7432. So
> that one for sure. And in addition there are others that have been
> implemented. For instance, Pref DF election has been implemented by
> multiple vendors.
> Thanks,
> Jorge
>
> ----------
> *From:* Muthu Arul Mozhi Perumal 
> *Sent:* Friday, March 22, 2019 10:41
> *To:* Rabadan, Jorge (Nokia - US/Mountain View)
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
> Hi Jorge,
>
> I didn't mean using different algorithms for electing the DF and BFD. I am
> just asking which algorithm is most widely implemented/used for electing
> the DF *and* BDF for EVPN VPWS single-active multihoming.
>
> Regards,
> Muthu
>
> On Fri, Mar 22, 2019 at 7:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
>> The implementations I know use the same DF Alg for DF election _*and*_
>> backup DF Election. And I don’t see why you would use something different?
>>
>> In other words, if you use e.g., Pref based DF Alg, use it for DF and BDF
>> elections. Only that the BDF election excludes the DF from the candidate
>> list.
>>
>>
>>
>> Thx
>>
>> Jorge
>>
>>
>>
>> *From:*BESS  on behalf of Muthu Arul Mozhi
>> Perumal 
>> *Date: *Friday, March 22, 2019 at 4:23 AM
>> *To: *"bess@ietf.org" 
>> *Subject: *[bess] BDF Election in EVPN VPWS Single-Active Multihoming
>>
>>
>>
>> While RFC 8214 doesn't recommend any DF election algorithm capable of
>> electing the BDF in EVPN VPWS single-active multihoming for deciding the
>> backup PE, any feedback on what is(are) the widely implemented/supported DF
>> election  algorithm(s) by vendors?
>>
>>
>>
>> Regards,
>>
>> Muthu
>>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

[Muthu Arul Mozhi Perumal]

Hi Jorge,

I didn't mean using different algorithms for electing the DF and BFD. I am
just asking which algorithm is most widely implemented/used for electing
the DF *and* BDF for EVPN VPWS single-active multihoming.

Regards,
Muthu

On Fri, Mar 22, 2019 at 7:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> The implementations I know use the same DF Alg for DF election _*and*_
> backup DF Election. And I don’t see why you would use something different?
>
> In other words, if you use e.g., Pref based DF Alg, use it for DF and BDF
> elections. Only that the BDF election excludes the DF from the candidate
> list.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *BESS  on behalf of Muthu Arul Mozhi
> Perumal 
> *Date: *Friday, March 22, 2019 at 4:23 AM
> *To: *"bess@ietf.org" 
> *Subject: *[bess] BDF Election in EVPN VPWS Single-Active Multihoming
>
>
>
> While RFC 8214 doesn't recommend any DF election algorithm capable of
> electing the BDF in EVPN VPWS single-active multihoming for deciding the
> backup PE, any feedback on what is(are) the widely implemented/supported DF
> election  algorithm(s) by vendors?
>
>
>
> Regards,
>
> Muthu
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] BDF Election in EVPN VPWS Single-Active Multihoming

[Muthu Arul Mozhi Perumal]

While RFC 8214 doesn't recommend any DF election algorithm capable of
electing the BDF in EVPN VPWS single-active multihoming for deciding the
backup PE, any feedback on what is(are) the widely implemented/supported DF
election  algorithm(s) by vendors?

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

[bess] Question on symmetric IRB procedures in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

draft-ietf-bess-evpn-inter-subnet-forwarding says the following in section
3.2.2:


   If the receiving PE receives this route with both the MAC-VRF and IP-
   VRF route targets but the MAC/IP Advertisement route does not include
   MPLS label2 field and if the receiving PE supports asymmetric IRB
   mode, then the receiving PE installs the MAC address in the
   corresponding MAC-VRF and  association in the ARP table for
   that tenant (identified by the corresponding IP-VRF route target).


Further below it says:


   If the receiving PE receives this route with both the MAC-VRF and IP-
   VRF route targets but the MAC/IP Advertisement route does not include
   MPLS label2 field and if the receiving PE does not support either
   asymmetric or symmetric IRB modes, then if it has the corresponding
   MAC-VRF, it only imports the MAC address


How should "does not support either asymmetric or symmetric IRB" be
interpreted? Should it be interpreted as "supports neither asymmetric nor
symmetric"? Or should it be interpreted as "does not support one of them"?

If it is the former, then the case where the receiving PE supports only
symmetric (but not asymmetric) IRB isn't described. It it is the later then
it includes the case where the receiving PE supports only asymmetric (but
not symmetric) IRB and what is described in that paragraph conflicts with
the first paragraph mentioned above.

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

[bess] Question on IRB MAC in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

draft-ietf-bess-evpn-inter-subnet-forwarding describes two ways of
provisioning the default gateway MAC and IP addresses on the IRB interface
associated with the corresponding subnet:


   1. All the PEs for a given tenant subnet use the same anycast default
   gateway IP and MAC addresses . On each PE, this default gateway IP
   and MAC addresses correspond to the IRB interface connecting the BT
   associated with the tenant's VLAN to the corresponding tenant's IP-
   VRF.

   2. Each PE for a given tenant subnet uses the same anycast default
   gateway IP address but its own MAC address. These MAC addresses are
   aliased to the same anycast default gateway IP address through the
   use of the Default Gateway extended community as specified in
   [RFC7432], which is carried in the EVPN MAC/IP Advertisement routes.


Further below it says:


   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).


In the above, it says the ARP response or NS will use the anycast MAC
address. The question is, how is this feasible if the second option of
provisioning
the default gateway MAC and IP addresses on the IRB interface are chosen,
where each PE for a given tenant subnet uses the same anycast default
gateway IP address but its own MAC address?

Should it instead say:
  the request is sent for the anycast IP address of the IRB interface
   associated with the TS's subnet and the reply will use *configured*
   MAC address?

i.e. s/anycast MAC/configured MAC?

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

[bess] Fwd: I-D Action: draft-ssm-bess-bgp-ec-evpn-vpws-00.txt

[Muthu Arul Mozhi Perumal]

Hi,

We just submitted a draft describing a new BGP extended community for use
in EVPN VPWS. Comments/suggestions welcome..

Regards,
Muthu

-- Forwarded message -
From: 
Date: Thu, Mar 7, 2019 at 8:59 PM
Subject: I-D Action: draft-ssm-bess-bgp-ec-evpn-vpws-00.txt
To: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : BGP Extended Community for Virtual Private Wire
Service Support in Ethernet VPN
Authors : Srikanth Ramaswamy
  Satishkumar Rodd
  Muthu Arul Mozhi Perumal
Filename: draft-ssm-bess-bgp-ec-evpn-vpws-00.txt
Pages   : 6
Date: 2019-03-07

Abstract:
   This document describes an optional BGP extended community for use in
   Ethernet VPN (EVPN) Virtual Private Wire Service (VPWS).  It helps in
   avoiding the situation where the EVPN VPWS instance is declared 'up'
   on one side but remains 'down' on the other side.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ssm-bess-bgp-ec-evpn-vpws/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ssm-bess-bgp-ec-evpn-vpws-00
https://datatracker.ietf.org/doc/html/draft-ssm-bess-bgp-ec-evpn-vpws-00


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming

[Muthu Arul Mozhi Perumal]

Thanks, Sasha.

Is my understanding for the all-active case correct?

It should be noted that in the scenario described by Chalapathi, only PE1
advertises the MAC/IP route for MAC1. PE2 and PE3 advertise only alias
labels..

Regards,
Muthu

On Thu, Mar 7, 2019 at 3:40 PM Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

>
>
> Muthu and all,
>
> Quoting from Section 14.1.1 “Single-Active Redundancy Mode”  of RFC 7432:
>
>
>
>If the primary PE encounters a failure, it MAY withdraw its set of
>
>Ethernet A-D per ES routes for the affected ES prior to withdrawing
>
>its set of MAC/IP Advertisement routes.
>
>
>
>If there is only one backup PE for a given ES, the remote PE MAY use
>
>the primary PE's withdrawal of its set of Ethernet A-D per ES routes
>
>as a trigger to update its forwarding entries, for the associated MAC
>
>addresses, to point towards the backup PE.  As the backup PE starts
>
>learning the MAC addresses over its attached ES, it will start
>
>sending MAC/IP Advertisement routes while the failed PE withdraws its
>
>routes.  This mechanism minimizes the flooding of traffic during
>
>fail-over events.
>
>
>
>If there is more than one backup PE for a given ES, the remote PE
>
>MUST use the primary PE's withdrawal of its set of Ethernet A-D per
>
>ES routes as a trigger to start flooding traffic for the associated
>
>MAC addresses (as long as flooding of unknown unicast packets is
>
>administratively allowed), as it is not possible to select a single
>
>backup PE.
>
>
>
> So there are actually three sub-cases in the single-active redundancy mode
> use case:
>
> 1.   The single-active multi-homed ES has been advertised by exactly
> two PEs. In this case withdrawal of the per-ES Ethernet A-D route by the
> primary PE may result in other PEs sending the unicast traffic for MAC
> addresses  learned from this ES to the secondary PE using the alias labels
> advertised for the corresponding EVI in the per-EVI Ethernet A-D routes.
>
> 2.   The  single-active multi-homed ES has been advertised by three
> or more PEs, and flooding of unknown unicast is allowed. In this case
> withdrawal of the per-ES Ethernet A-D route by the primary PE MUST result
> in flooding of the unicast traffic with unlearned MAC addresses using the
> common scheme for BUM traffic. The Aliasing labels are not relevant for
> this use case.
>
> 3.The  single-active multi-homed ES has been advertised by three
> or more PEs, and flooding of unknown unicast is not allowed. In this case
> withdrawal of the per-ES Ethernet A-D route by the primary PE MUST in just
> local flooding of the unicast traffic with unlearned MAC addresses.
>
>
>
> Hope this helps.
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* BESS  *On Behalf Of *Muthu Arul Mozhi
> Perumal
> *Sent:* Thursday, March 7, 2019 8:53 AM
> *To:* Luc Andre Burdet (lburdet) 
> *Cc:* chalapathi andhe ; Sean Wu <
> sean...@ericsson.com>; Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>; bess@ietf.org;
> chalapathi.an...@ericsson.com
> *Subject:* Re: [bess] FW: Regarding the Alias label usage in EVPN
> Multihoming
>
>
>
> My understanding:
>
>
>
> For the single-active case in the diagram below, when PE4 receives the A-D
> per ES route withdraw it won't know whether PE2 or PE3 will become the new
> primary/DF for the , so it will start flooding the traffic
> destined to MAC1. Then either PE2 or PE3 will become the new primary/DF for
> the  and advertise the MAC/IP route for MAC1. PE4 will then start
> sending the traffic destined to MAC1 to the new primary.
>
>
>
> For the all-active case, when PE4 receives the A-D per ES route withdraw
> it will update the nexthop list for MAC1 by removing PE1 from that list.
> PE4 will then load balance the traffic destined to MAC1 by send it to PE2
> and PE3 using alias label.
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Wed, Mar 6, 2019 at 7:51 PM Luc Andre Burdet (lburdet) <
> lbur...@cisco.com> wrote:
>
> Hi Chalu,
>
>
>
> Please read 7432 s.8.4: in single-active it is not an aliasing
> label/procedure but a backup-path procedure.
>
> It will answer your questions (both, actually).
>
>
>
> There is no flooding once the MAC is learnt & distributed: cf. that’s the
> point.
>
>
>
>
>
> [image:
> http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]

Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming

[Muthu Arul Mozhi Perumal]

My understanding:

For the single-active case in the diagram below, when PE4 receives the A-D
per ES route withdraw it won't know whether PE2 or PE3 will become the new
primary/DF for the , so it will start flooding the traffic
destined to MAC1. Then either PE2 or PE3 will become the new primary/DF for
the  and advertise the MAC/IP route for MAC1. PE4 will then start
sending the traffic destined to MAC1 to the new primary.

For the all-active case, when PE4 receives the A-D per ES route withdraw it
will update the nexthop list for MAC1 by removing PE1 from that list. PE4
will then load balance the traffic destined to MAC1 by send it to PE2 and
PE3 using alias label.

Regards,
Muthu

On Wed, Mar 6, 2019 at 7:51 PM Luc Andre Burdet (lburdet) 
wrote:

> Hi Chalu,
>
>
>
> Please read 7432 s.8.4: in single-active it is not an aliasing
> label/procedure but a backup-path procedure.
>
> It will answer your questions (both, actually).
>
>
>
> There is no flooding once the MAC is learnt & distributed: cf. that’s the
> point.
>
>
>
>
>
> [image:
> http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]
>
> *Luc André Burdet*
>
> lbur...@cisco.com
>
> Tel: *+1 613 254 4814*
>
> Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
>
> Cisco.com 
>
>
>
>
>
> *From: *BESS  on behalf of chalapathi andhe <
> chalu.i...@gmail.com>
> *Date: *Wednesday, March 6, 2019 at 04:15
> *To: *"bess@ietf.org" 
> *Cc: *Sean Wu , Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>, "chalapathi.an...@ericsson.com" <
> chalapathi.an...@ericsson.com>
> *Subject: *Re: [bess] FW: Regarding the Alias label usage in EVPN
> Multihoming
>
>
>
>
>
>
>
> Hi All,
>
>
>
> Can you please help us on the following issue.
>
> In the following diagram, PE1, PE2, PE3 are connected to the same ES [ES1]
> in Single active mode, and PE4 is a remote PE.
>
> Let’s say PE1 is advertising the MAC1 route, PE4 will install the MAC1
> with the PE1 as primary path with MAC Label,
>
> and PE2, PE3 as backup with the Alias Label. Now if the PE1 to CE1 link
> goes down, then PE1 withdraw the EAD/ES route
>
> which will be processed by PE4.
>
> Now what should the forwarding state at PE4 ?, PE4 should update the
> forwarding state of MAC1 with the PE2, PE3 Alias label
>
> and any traffic destined to MAC1 should be flooded to PE2, PE3 with the
> Alias labels ?
>
> Or packet should be flooded to PE2, PE3 with the Flood labels ? Or should
> it be some other method ?
>
>
>
> In similar if the ES is operating in all active mode, what should be the
> forwarding state at PE4 ?
>
> PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias
> label
>
> and any traffic destined to MAC1 should be sent to either PE2 or PE3 with
> the Alias labels [ not flood to both] ?
>
> Or packet should be flooded to PE2, PE3 with the Flood labels  or Alias
> Label ?
>
> Or should it be some other method ?
>
>
>
>
>
> [image: cid:1695247dcc04ce8e91]
>
>
>
>
>
> Thanks,
>
> Chalapathi.
>
> ___
> 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] Mobility procedure in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Sounds good and both of my earlier comments are addressed in -07.

thanks,
Muthu

On Tue, Feb 12, 2019 at 8:32 AM Ali Sajassi (sajassi) 
wrote:

>
>
> Mobility procedures for asymmetric IRB is very similar to symmetric IRB
> except for ARP response handling by the source NVE. So, I added the
> following sentence to the sections 4.1, 4.2, and 4.3 in rev07.
>
>
>
> “In case of the asymmetric IRB, the source NVE also updates its ARP table
> with the received adjacency information and in case of the symmetric IRB,
> the source NVE removes the entry associated with the received 
> from its local ARP table.”
>
>
>
> Cheers,
>
> Ali
>
>
>
> *From: *BESS  on behalf of Muthu Arul Mozhi
> Perumal 
> *Date: *Tuesday, February 5, 2019 at 8:22 PM
> *To: *"bess@ietf.org" 
> *Subject: *[bess] Mobility procedure in
> draft-ietf-bess-evpn-inter-subnet-forwarding
>
>
>
> Section 4 (Mobility Procedure) of the draft says the following:
>
>
>
>This section describes mobility procedures for both
>
>symmetric and asymmetric IRB.
>
>
>
> However, it describes the mobility procedure only for symmetric IRB
> (section 4.1). Mobility procedure for asymmetric IRB is not described in
> the draft.
>
>
>
> Is the mobility procedure for asymmetric IRB expected to be described in
> an upcoming version of the draft?
>
>
>
> Regards,
>
> Muthu
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Minor comment on draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Section 6.2.1 says the following:

   Each NVE advertises a Route Type-5 (RT-5, IP Prefix Route defined in
   [EVPN-PREFIX]) for each of its subnet prefixes with the IP address of
   its TS as the next hop (gateway address field) as follow:

   - RD associated with the IP-VRF
   - ESI = 0
   - Ethernet Tag = 0;
   - IP Prefix Length = 32 or 128
   - IP Prefix = SNi
   - Gateway Address = IPi; IP address of TS
   - Label = 0

Here, s/IP Prefix Length = 32 or 128/IP Prefix Length = 0 to 32 or 0 to 128

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

[bess] Mobility procedure in draft-ietf-bess-evpn-inter-subnet-forwarding

[Muthu Arul Mozhi Perumal]

Section 4 (Mobility Procedure) of the draft says the following:

   This section describes mobility procedures for both
   symmetric and asymmetric IRB.

However, it describes the mobility procedure only for symmetric IRB
(section 4.1). Mobility procedure for asymmetric IRB is not described in
the draft.

Is the mobility procedure for asymmetric IRB expected to be described in an
upcoming version of the draft?

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

[bess] Signaling Control Word in EVPN

[Muthu Arul Mozhi Perumal]

RFC 8214 (EVPN VPWS) introduces a new EVPN Layer 2 Attributes extended
community for signaling the L2 MTU and other control flags, including the
one to signal that the control word needs to be included when sending
packets to this PE. It further describes how MTU checking is to be
performed when signaled using this extended community.

RFC 7432 however is completely silent about it. Is the extended community
described in RFC 8214 expected to used in EVPN (VPLS) as well to signal
things like the usage of control word?

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

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Muthu Arul Mozhi Perumal]

Thanks, Jorge.

In EVPN single-active dual-homing or EVPN VPWS single-active multi-homing,
when other PEs realize that the DF is dead, they all need to re-run the DF
election for sure. However, traffic recovery need not wait until the DF
election gets over electing a new DF..it only requires the other PEs and
the backup to realize the primary/DF is dead and start forward. That's my
point..

Regards,
Muthu

On Fri, Oct 5, 2018 at 1:30 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Muthu,
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Thursday, October 4, 2018 at 5:37 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"jaikumar.somasunda...@ericsson.com" <
> jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" , "
> jiang...@ericsson.com" , "
> p.muthu.arul.mo...@ericsson.com" 
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Thanks, Jorge. This is inline with my thinking. So, in single-active
> multihoming, once the primary is dead we don't need to wait for the DF
> election to happen for the backup (or some other PE in the ES) to become
> active and start forwarding traffic over the ES, instead it only requires
> the remote PEs and backup to realize that the primary is dead (thru' NH
> tracking / BFD) and start forwarding over the ES, right?
>
> [JORGE] When the other PEs in the ES realize the DF is dead, they need to
> remove the dead PE from the candidate list and run DF Election. You may
> optimize things if you only have two PEs in the ES (such as skip the timer)
> but if you have more than 2 PEs in the ES, there is really no concept of
> backup PE in RFC7432, but simply the other PEs are non-DF. However, the
> concept of backup PE in an ES with more than two PEs is specified in
> RFC8214, where all the PEs in the ES not only elect a DF but also a backup
> DF, and signal this backup condition in the AD per-EVI routes. Note this is
> not there in RFC7432.
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> Muthu,
>
>
>
> About this:
>
>
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> No, not in the implementations I know of. Next Hop tracking will
> immediately detect that the PE is not in the network anymore and the routes
> will be invalidated. You can also bootstrap the BGP sessions to BFD.
>
> But that has nothing to do with EVPN!.. it’s regular BGP.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Thursday, October 4, 2018 at 1:14 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"jaikumar.somasunda...@ericsson.com" <
> jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" , "
> jiang...@ericsson.com" , "
> p.muthu.arul.mo...@ericsson.com" 
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Please see inline..
>
>
>
> On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram 
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *RE: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Thanks Jorge for the quick reply.
>
> Please find further question below.
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) 
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram ;
> bess@ietf.org
> *Cc:* Jiang He ; P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject:* Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Hi,
>
>
>
> Questions:
>
> 1.   Will the node in backup mode forward the packet to CE?
>
> [JORGE] as soon as it becomes DF it can forward packets to the CE. The
> backup node will have to run DF election upon the ES route withdrawal from
> the primary. If AC-DF is enabled, it can also react to the wit

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Muthu Arul Mozhi Perumal]

Thanks, Jorge. This is inline with my thinking. So, in single-active
multihoming, once the primary is dead we don't need to wait for the DF
election to happen for the backup (or some other PE in the ES) to become
active and start forwarding traffic over the ES, instead it only requires
the remote PEs and backup to realize that the primary is dead (thru' NH
tracking / BFD) and start forwarding over the ES, right?

Regards,
Muthu

On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Muthu,
>
>
>
> About this:
>
>
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> No, not in the implementations I know of. Next Hop tracking will
> immediately detect that the PE is not in the network anymore and the routes
> will be invalidated. You can also bootstrap the BGP sessions to BFD.
>
> But that has nothing to do with EVPN!.. it’s regular BGP.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Thursday, October 4, 2018 at 1:14 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"jaikumar.somasunda...@ericsson.com" <
> jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" , "
> jiang...@ericsson.com" , "
> p.muthu.arul.mo...@ericsson.com" 
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Please see inline..
>
>
>
> On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram 
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *RE: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Thanks Jorge for the quick reply.
>
> Please find further question below.
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) 
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram ;
> bess@ietf.org
> *Cc:* Jiang He ; P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject:* Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Hi,
>
>
>
> Questions:
>
> 1.   Will the node in backup mode forward the packet to CE?
>
> [JORGE] as soon as it becomes DF it can forward packets to the CE. The
> backup node will have to run DF election upon the ES route withdrawal from
> the primary. If AC-DF is enabled, it can also react to the withdrawal of AD
> routes from the primary PE.
>
> *[Jai] Does that mean if any packet comes to a node that is still in the
> backup mode will get dropped, before the new DF election is complete? Why
> cant this be used as FRR? Or what is the use case of having backup node(s)?*
>
> *[JORGE2] when the primary node fails, ES and AD routes are withdrawn. *
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> Regards,
>
> Muthu
>
> *The AD route withdrawal is an indication for remote nodes that they have
> to send traffic to the backup (for a given MAC) or to flush the MACs if
> there are more than 2 PEs in the ES. Around the same time or maybe earlier,
> the ES route withdrawal will make the backup PE take over as DF. So the
> overall convergence time will depend on how/when those two things happen in
> time. Only the DF PE can forward traffic. A non-DF can never forward
> traffic or there will be risk of duplicate packets.*
>
>
>
> 2.   Will all the nodes in backup mode forward the packet before DF
> election?
>
> [JORGE] Only the new DF can forward.
>
>
>
> 3. If they forward, how is duplicate packets handled, in this case?
>
> [JORGE] see above.
>
>
>
> My two cents..
>
>
>
> Thanks.
>
> Jorge
>
>
>
>
>
>
>
> *From: *BESS  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Thurs

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Muthu Arul Mozhi Perumal]

Please see inline..

On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram 
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *RE: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Thanks Jorge for the quick reply.
>
> Please find further question below.
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) 
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram ;
> bess@ietf.org
> *Cc:* Jiang He ; P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject:* Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Hi,
>
>
>
> Questions:
>
> 1.   Will the node in backup mode forward the packet to CE?
>
> [JORGE] as soon as it becomes DF it can forward packets to the CE. The
> backup node will have to run DF election upon the ES route withdrawal from
> the primary. If AC-DF is enabled, it can also react to the withdrawal of AD
> routes from the primary PE.
>
> *[Jai] Does that mean if any packet comes to a node that is still in the
> backup mode will get dropped, before the new DF election is complete? Why
> cant this be used as FRR? Or what is the use case of having backup node(s)?*
>
> *[JORGE2] when the primary node fails, ES and AD routes are withdrawn. *
>
Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
session would timeout causing the primary PE's neighbors to flush out the
A-D routes received from the primary PE, right? This can take several
seconds, isn't it?

Regards,
Muthu

> *The AD route withdrawal is an indication for remote nodes that they have
> to send traffic to the backup (for a given MAC) or to flush the MACs if
> there are more than 2 PEs in the ES. Around the same time or maybe earlier,
> the ES route withdrawal will make the backup PE take over as DF. So the
> overall convergence time will depend on how/when those two things happen in
> time. Only the DF PE can forward traffic. A non-DF can never forward
> traffic or there will be risk of duplicate packets.*
>
>
>
> 2.   Will all the nodes in backup mode forward the packet before DF
> election?
>
> [JORGE] Only the new DF can forward.
>
>
>
> 3. If they forward, how is duplicate packets handled, in this case?
>
> [JORGE] see above.
>
>
>
> My two cents..
>
>
>
> Thanks.
>
> Jorge
>
>
>
>
>
>
>
> *From: *BESS  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 10:03 AM
> *To: *"bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> p.muthu.arul.mo...@ericsson.com>
> *Subject: *[bess] EVPN MH: Backup node behavior in Primary Path Failure
>
>
>
> Hello Everyone,
>
>
>
> Sorry if it is a duplicate. I repost this query as I did not receive any
> response yet.
>
> (I was wondering if this mail already reached the group or not)
>
>
>
> I have a question on Primary PE encountering a failure in EVPN multihoming
>
> in single active mode.
>
>
>
> RFC7432, section 14.1.1:
>
> 
>
>If there is more than one backup PE for a given ES, the remote PE
>
>MUST use the primary PE's withdrawal of its set of Ethernet A-D per
>
>ES routes as a trigger to start flooding traffic for the associated
>
>MAC addresses (as long as flooding of unknown unicast packets is
>
>administratively allowed), as it is not possible to select a single
>
>backup PE.
>
> 
>
>
>
> Questions:
>
> 1. Will the node in backup mode forward the packet to CE?
>
> 2. Will all the nodes in backup mode forward the packet before DF election?
>
> 3. If they forward, how is duplicate packets handled, in this case?
>
>
>
> Please help me anwere these questions.
>
>
>
> Thanks & Regards
>
> Jaikumar S
>
>
> ___
> 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