Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

Hi Greg,

Thank you very much for your clarification!
I made a mistake that I thought the BFD session is the base solution for UMH 
failover. 
Now I get it. Thank you!
BTW: In section 3.1.2, "draft-ietf-rtgwg-bgp-pic-08" may be mentioned as 
another example like MPLS FRR.

Thanks,
Sandy
--原始邮件--
发件人：GregMirsky 
收件人：张征7940;
抄送人：zzh...@juniper.net ;bess-cha...@ietf.org 
;Thomas Morin ;Robert Kebler 
;BESS ;
日 期 ：2019年02月14日 10:38
主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover
Hi Sandy,
thank you for your kind consideration of the proposed updates. I've logged my 
answers under GIM3>> tag.

Regards,
Greg

On Mon, Feb 11, 2019 at 11:44 PM  wrote:
Hi Greg,
Thank you for your good modification and clarification!
About two sections I still have some comments, I copy the contents here because 
the mail is too long:
1,
3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision.
GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a 
combination of conditions (the combination being determined by policy) to 
control the state of the BFD session, e.g., set it to AdminDown. I think that 
the use of policy to control the conditions that affect the P-tunnel reception 
state is the advantage of the proposed solution. What do you think?
4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?
GIM2>> As above, this is one of the conditions, controlled by the policy, that 
may be considered to influence the state of the BFD session.
Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE can 
get the tunnel states by BFD detection timer expiration. So administrator may 
choose different policies to control the session state, but the bfd packets 
detection should be the base. IMO section 3.1.1~4 are optional.
GIM3>> I re-read the 3.1 and I think now better understand the original idea. 
All methods listed in sub-sections, including the one that describes use of 
p2mp BFD, are alternatives, options to detect a failure in the tunnel. Would 
the following update be helpful:
OLD TEXT:
The procedure proposed here also allows that all downstream PEs don't
apply the same rules to define what the status of a P-tunnel is
(please see Section 6), and some of them will produce a result that
may be different for different downstream PEs.
NEW TEXT:
The optional procedures proposed in this section also allow that all downstream 
PEs don't
apply the same rules to define what the status of a P-tunnel is
(please see Section 6), and some of them will produce a result that
may be different for different downstream PEs.

For section 3.1.5 counter information, how do the configurable timer work with 
the bfd detection timer? What should egress PE do with the expiration of the 
two timers when they are both used?
GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast 
restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD per 
protected link. If that's the case, for the scenario described in this 
sub-section, p2mp BFD is unnecessary.

2.
For section 3.1.7.1, the last sentence.
GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be sent 
and the new p2mp BFD session must be initiated. Your question, as I interpret 
it, is to how operationally an implementation can minimize the disruption when 
the new BFD session advertised to replace one that already exists. Firstly, 
would we agree that sending the new BGP-BFD Discriminator and starting the new 
p2mp BFD session when the RPF interface changes is the right action? If we 
agree, then I can add a sentence or two to describe optional procedure for the 
upstream PE to minimize the disruption when the egress PE switches to the new 
p2mp BFD session.
Sandy2>If the "old" BFD discriminator can be reused in the new advertisement 
when the switchover is happened on a same upstream PE? If the "old" 
discriminator can be reused, it seems like it isn't necessary to build a new 
BFD session. But if a new BFD discriminator MUST be generated, then the new add 
sentence looks good to me.
GIM3>> Would the following update to the last paragraph address your concern:
OLD TEXT:
If the route to the
src/RP changes such that the RPF interface is changed to be a new PE-
CE interface, then the upstream PE will update the S-PMSI A-D route
with included BGP-BFD Attribute so that value of the BFD
Discriminator is associated with the new RPF link.
NEW TEXT:
If the route to the
src/RP changes such that the RPF interface is changed to be a new PE-
CE interface, then the upstream PE will update the S-PMSI A-D route
with included BGP-BFD Attribute so that the previously advertised value of the 
BFD
Discriminator is associated with the new RPF link.

Thanks

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Greg Mirsky]

Hi Sandy,
thank you for your kind consideration of the proposed updates. I've logged
my answers under GIM3>> tag.

Regards,
Greg

On Mon, Feb 11, 2019 at 11:44 PM  wrote:

> Hi Greg,
>
> Thank you for your good modification and clarification!
> About two sections I still have some comments, I copy the contents here
> because the mail is too long:
> 1,
> 3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI
> tunnel's state influence the BFD session, there is no need for other
> decision.
> GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a
> combination of conditions (the combination being determined by policy) to
> control the state of the BFD session, e.g., set it to AdminDown. I think
> that the use of policy to control the conditions that affect the P-tunnel
> reception state is the advantage of the proposed solution. What do you
> think?
> 4. For section 3.1.5, IMO the counter method has no relationship with the
> BFD function defined in this document. If the counter method will be used
> as a supplement for BFD session?
> GIM2>> As above, this is one of the conditions, controlled by the policy,
> that may be considered to influence the state of the BFD session.
> Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE
> can get the tunnel states by BFD detection timer expiration. So
> administrator may choose different policies to control the session state,
> but the bfd packets detection should be the base. IMO section 3.1.1~4 are
> optional.
>
GIM3>> I re-read the 3.1 and I think now better understand the original
idea. All methods listed in sub-sections, including the one that describes
use of p2mp BFD, are alternatives, options to detect a failure in the
tunnel. Would the following update be helpful:
OLD TEXT:
   The procedure proposed here also allows that all downstream PEs don't
   apply the same rules to define what the status of a P-tunnel is
   (please see Section 6), and some of them will produce a result that
   may be different for different downstream PEs.
NEW TEXT:
   The optional procedures proposed in this section also allow that all
downstream PEs don't
   apply the same rules to define what the status of a P-tunnel is
   (please see Section 6), and some of them will produce a result that
   may be different for different downstream PEs.

For section 3.1.5 counter information, how do the configurable timer work
> with the bfd detection timer? What should egress PE do with the expiration
> of the two timers when they are both used?
>
GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast
restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD
per protected link. If that's the case, for the scenario described in this
sub-section, p2mp BFD is unnecessary.

>
> 2.
> For section 3.1.7.1, the last sentence.
> GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be
> sent and the new p2mp BFD session must be initiated. Your question, as I
> interpret it, is to how operationally an implementation can minimize the
> disruption when the new BFD session advertised to replace one that already
> exists. Firstly, would we agree that sending the new BGP-BFD Discriminator
> and starting the new p2mp BFD session when the RPF interface changes is the
> right action? If we agree, then I can add a sentence or two to describe
> optional procedure for the upstream PE to minimize the disruption when the
> egress PE switches to the new p2mp BFD session.
> Sandy2>If the "old" BFD discriminator can be reused in the new
> advertisement when the switchover is happened on a same upstream PE? If the
> "old" discriminator can be reused, it seems like it isn't necessary to
> build a new BFD session. But if a new BFD discriminator MUST be generated,
> then the new add sentence looks good to me.
>
GIM3>> Would the following update to the last paragraph address your
concern:
OLD TEXT:
   If the route to the
   src/RP changes such that the RPF interface is changed to be a new PE-
   CE interface, then the upstream PE will update the S-PMSI A-D route
   with included BGP-BFD Attribute so that value of the BFD
   Discriminator is associated with the new RPF link.
NEW TEXT:
   If the route to the
   src/RP changes such that the RPF interface is changed to be a new PE-
   CE interface, then the upstream PE will update the S-PMSI A-D route
   with included BGP-BFD Attribute so that the previously advertised value
of the BFD
   Discriminator is associated with the new RPF link.

>
> Thanks,
> Sandy
>
> --原始邮件--
> 发件人：GregMirsky 
> 收件人：张征7940;
> 抄送人：zzh...@juniper.net ;bess-cha...@ietf.org <
> bess-cha...@ietf.org>;Thomas Morin ;Robert
> Kebler ;BESS ;
> 日 期 ：2019年02月07日 08:16
> 主 题 ：Re: [bess] WGLC,IPR and implementation poll for
> draft-ietf-bess-mvpn-fast-failover
> Hi Sandy,much appreciate your comments. Please find my answers below
> tagged GIM2>>.
> Attached, please find the upda

Re: [bess] A question on CE behavior on traffic forwarding to EVPN multihomed PEs in single-active mode

[Jaikumar Somasundaram]

Thanks Mrinmoy for the quick answer.

Thanks & Regards
Jaikumar S

From: Mrinmoy Ghosh (mrghosh) 
Sent: Wednesday, February 13, 2019 1:21 PM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: Pradeep Ramakrishnan ; Chalapathi Andhe 

Subject: RE: A question on CE behavior on traffic forwarding to EVPN multihomed 
PEs in single-active mode

Hi Jaikumar,

EVPN Single active heavily depends upon MAC Flush mechanism like MVRP or TCN 
Flush.

In your topology, initially CE1 would flood unknown ucast to both PE1 and PE2; 
PE1 being DF will send and receive traffic for that (ES, EVI), hence once the 
traffic  will be learned eventually from PE1.
However on switchover, Mac flush is sent to CE so that the forwarding table is 
flushed and the traffic is flooded to both PE until learned from the new DF.

Thanks,
Mrinmoy

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Jaikumar Somasundaram
Sent: Tuesday, February 12, 2019 10:11 PM
To: bess@ietf.org
Cc: Pradeep Ramakrishnan 
mailto:pradeep.ramakrish...@ericsson.com>>; 
Chalapathi Andhe 
mailto:chalapathi.an...@ericsson.com>>
Subject: [bess] A question on CE behavior on traffic forwarding to EVPN 
multihomed PEs in single-active mode

Hello All,

In EVPN MH with Single-Active scenario, could you help us to clarify the below 
query?

 --
 ||
   PORT1 |  DEVICE1   |PORT3
   --| PE1|-
   |  1/5|  2.2.2.2   | 1/4 |
   | || |
   | -- |
   |PORT1  |PORT2   |PORT2
--| ++--
 ||| |||
|
 | DEVICE4|| ||PORT1   | DEVICE4
|
 | (CE1)  || |   DEVICE3  || (CE2)  
|
 | Multi-home || | PE |   PORT3| Single 
home|
 ||| |   4.4.4.4  ||
|
--| ++--
   |PORT2  |1/1|PORT3
   |   |PORT2  | 1/6
   | --|
   | |||
   |   PORT1 |  DEVICE2   ||
   --|PE2 |-
1/4  |  3.3.3.3   |PORT3
 ||1/4
 --

Let's say CE1 is connected to PE1 and PE2 (single-active case)
and PE1 is the DF for VLAN 10 and has the active link,
but CE1 sends unknown unicast traffic on the link to PE2 (standby link),
wouldn't the traffic be dropped because its non-DF ?

or

How does CE ensure traffic is always forwarded on the active link
(as standby link will drop the traffic) ?

Thanks & Regards
Jaikumar S

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

Re: [bess] A question on CE behavior on traffic forwarding to EVPN multihomed PEs in single-active mode

[Yu Tianpeng]

I guess it worth clarify CE using LAG or L2 switching to connect to PE in
the question.
Thanks
Tim


On Wed, 13 Feb 2019, 07:51 Mrinmoy Ghosh (mrghosh)  Hi Jaikumar,
>
>
>
> EVPN Single active heavily depends upon MAC Flush mechanism like MVRP or
> TCN Flush.
>
>
>
> In your topology, initially CE1 would flood unknown ucast to both PE1 and
> PE2; PE1 being DF will send and receive traffic for that (ES, EVI), hence
> once the traffic  will be learned eventually from PE1.
>
> However on switchover, Mac flush is sent to CE so that the forwarding
> table is flushed and the traffic is flooded to both PE until learned from
> the new DF.
>
>
>
> Thanks,
>
> Mrinmoy
>
>
>
> *From:* BESS  *On Behalf Of * Jaikumar Somasundaram
> *Sent:* Tuesday, February 12, 2019 10:11 PM
> *To:* bess@ietf.org
> *Cc:* Pradeep Ramakrishnan ;
> Chalapathi Andhe 
> *Subject:* [bess] A question on CE behavior on traffic forwarding to EVPN
> multihomed PEs in single-active mode
>
>
>
> Hello All,
>
>
>
> In EVPN MH with Single-Active scenario, could you help us to clarify the
> below query?
>
>
>
>  --
>
>  ||
>
>PORT1 |  DEVICE1   |PORT3
>
>--| PE1|-
>
>|  1/5|  2.2.2.2   | 1/4 |
>
>| || |
>
>| -- |
>
>|PORT1  |PORT2   |PORT2
>
> --| ++
> --
>
>  ||| ||
> ||
>
>  | DEVICE4|| ||PORT1   |
> DEVICE4|
>
>  | (CE1)  || |   DEVICE3  ||
> (CE2)  |
>
>  | Multi-home || | PE |   PORT3|
> Single home|
>
>  ||| |   4.4.4.4  |
> ||
>
> --| ++
> --
>
>|PORT2  |1/1|PORT3
>
>|   |PORT2  | 1/6
>
>| --|
>
>| |||
>
>|   PORT1 |  DEVICE2   ||
>
>--|PE2 |-
>
> 1/4  |  3.3.3.3   |PORT3
>
>  ||1/4
>
>  --
>
>
>
> Let’s say CE1 is connected to PE1 and PE2 (single-active case)
>
> and PE1 is the DF for VLAN 10 and has the active link,
>
> but CE1 sends unknown unicast traffic on the link to PE2 (standby link),
>
> wouldn’t the traffic be dropped because its non-DF ?
>
>
>
> or
>
>
>
> How does CE ensure traffic is always forwarded on the active link
>
> (as standby link will drop the traffic) ?
>
>
>
> 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