Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

["Shah, Himanshu" <[e-mail]>]

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing
important role for this to be clean.

Thanks,
Himanshu

From: Sami Boutros [mailto:[e-mail]]
Sent: Wednesday, February 08, 2017 7:12 PM
To: Shah, Himanshu <[e-mail]>; Rabadan, Jorge (Nokia - US) <[e-mail]>; Sami Boutros <[e-mail]>; Iftekhar Hussain <[e-mail]>
Cc: Jeffrey Zhang <[e-mail]>; Alvaro Retana (aretana) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07



From: "Shah, Himanshu" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" <[e-mail]<mailto:[e-mail]>>, Sami Boutros <[e-mail]<mailto:[e-mail]>>, Sami Boutros <[e-mail]<mailto:[e-mail]>>, Iftekhar Hussain <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Zhang <[e-mail]<mailto:[e-mail]>>, "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept only one as B=1 (may be to his liking..:-))

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the draft say this happen only in transit scenarios as in  the following text.. for a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE receiving P=1 from more than one PE will select the last advertising PE as the primary PE when forwarding traffic. A remote PE receiving B=1 from more than one PE will select only one backup PE. A remote PE MUST receive P=1 from at least one PE before forwarding traffic.

Thanks,

Sami

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:[e-mail]]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros <[e-mail]<mailto:[e-mail]>>; Shah, Himanshu <[e-mail]<mailto:[e-mail]>>; Sami Boutros <[e-mail]<mailto:[e-mail]>>; Iftekhar Hussain <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Zhang <[e-mail]<mailto:[e-mail]>>; Alvaro Retana (aretana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how many backup or redundant nodes can be in an ethernet-segment, and how many of them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in which case there are more than 1 redundant PEs, but only one PE should signal B=1 at the time. Since there may be transient windows where the remote PE gets 2 P=1s or 2 B=1s, we need to define what to do, but it doesn’t mean that is a normal steady state.

In a nutshell, Primary will send P=1,B=0. Backup will send P=0,B=1 and the rest of the redundant PEs in the ES will send P=0,B=0. If the primary PE/ES fails, the remote PEs will immediately send to the backup. In the meantime, there is a DF reelection, and there will be a new primary and new backup that will signal the bits as per the above. The remote PE will always send to the primary first and if not present to the backup.

I think all this is in the draft though…

Thanks.
Jorge


On 2/9/17, 12:39 AM, "Sami Boutros" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Himanshu,


From: "Shah, Himanshu" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros <[e-mail]<mailto:[e-mail]>>, Sami Boutros <[e-mail]<mailto:[e-mail]>>, Iftekhar Hussain <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Zhang <[e-mail]<mailto:[e-mail]>>, "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.
----
[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.
----
   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding
----
[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

[Sami] But wouldn’t the text highlighted here clarify the text above, that only one Backup should be selected.

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

[Sami] Why the limitation? Any reason? For PW redundancy we do support too multiple backups, however for
a given PW only one backup will be selected, exactly the same as here.

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.

[Sami] DF election is intentionally not in scope, not to redefine any mechanisms in Base 7432 or other drafts like
draft-ietf-bess-evpn-df-election.

Thanks,

Sami

Thanks,
Himanshu

From: Sami Boutros [mailto:[e-mail]]
Sent: Tuesday, February 07, 2017 6:06 PM
To: Shah, Himanshu <[e-mail]<mailto:[e-mail]>>; Sami Boutros <[e-mail]<mailto:[e-mail]>>; Iftekhar Hussain <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Zhang <[e-mail]<mailto:[e-mail]>>; Alvaro Retana (aretana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros <[e-mail]<mailto:[e-mail]>>, Sami Boutros <[e-mail]<mailto:[e-mail]>>, Iftekhar Hussain <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Zhang <[e-mail]<mailto:[e-mail]>>, "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

It seems to me that single-active multihoming case could use some more clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can definitely tell
to each other as well as to remote PE who/what primary election order would be.

[Sami] In single active, there would be only one primary as per definition below in this e-mail.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

[Sami] Extending the DF election is not in scope for the draft and I doubt we will include it, however there are other drafts extending DF election like rabadan-evpn-pref-df.

The text in VPWS draft is not very clear.

It seems to suggest there could be multiple primaries and backups.
But if that is true how would remote PE can independently switchover to backup PE
(i.e. which backup PE?).

[Sami] As per draft, "A remote PE receiving B=1 from more than one PE will select only one backup PE."

If there are multiple primary PEs, and if one of them fail, why not switchover to other
primary PE, so on and so forth..

[Sami] In single active there should be only one primary, having more than one primary will be transit in this case.

So what is the intent?

[Sami] As per EVPN, the intent is to support A/A in which all will be primary, or A/S in which only one primary and one backup.

One primary, one backup
Multiple primary, one backup
Or (one or) multiple primaries, multiple backups?

[Sami] We are not redefining what single active or all active mean, this is as per EVPN RFC7432

Single-Active Redundancy Mode: When only a single PE, among all the

      PEs attached to an Ethernet segment, is allowed to forward traffic

      to/from that Ethernet segment for a given VLAN, then the Ethernet

      segment is defined to be operating in Single-Active redundancy

      mode.



I.e. One primary and one/multiple backup.



   All-Active Redundancy Mode: When all PEs attached to an Ethernet

      segment are allowed to forward known unicast traffic to/from that

      Ethernet segment for a given VLAN, then the Ethernet segment is

      defined to be operating in All-Active redundancy mode.

 I.e. Multiple Primary


Also, there has to be corresponding understanding/configuration in CE as well.
So if the CE+multi-hommed-PEs configuration is consistent and if all the parties,
(CE, multi-homed PEs and remote PE) are aware of this, selection algorithm would work better?

[Sami] Again, we are not redefining EVPN multihoming or DF election, those are following base EVPN.

Thanks,

Sami

Thanks,
Himanshu

From: BESS [mailto:[e-mail]] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: Sami Boutros <[e-mail]<mailto:[e-mail]>>; Iftekhar Hussain <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Zhang <[e-mail]<mailto:[e-mail]>>; Alvaro Retana (aretana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels associated with a pair of endpoints. Each label is downstream assigned and advertised by the disposition PE through an Ethernet A-D per-EVI route. The downstream label identifies the endpoint on the disposition PE. A VPWS service instance can be associated with only one VPWS service identifier.

Thanks,

Sami