date:20181009

Re: [bess] Signaling Control Word in EVPN

2018-10-09 Thread Andrew G. Malis

James,

Agreed. We touched on that in section 7 of draft-ietf-pals-ethernet-cw,
where we advised operators that enabling post-CW DPI for ECMP calculations
could cause misordering.

Cheers,
Andy


On Tue, Oct 9, 2018 at 10:35 AM James Bensley  wrote:

> On Tue, 9 Oct 2018 at 15:16, Andrew G. Malis  wrote:
> >
> > James,
>
> Hi Andy,
>
> > It's much harder to mandate use of EL than the CW for several reasons:
>
> I didn't say it should be mandated, but recommended.
>
> > - CW implementation is much more common than EL implementation
> > - PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel,
> rather, they will be multiplexed with other MPLS-based applications that
> are using the traffic tunnel to reach a common destination. Thus, by using
> the CW, you can disable ECMP only for those MPLS packets that cannot
> tolerate reordering.
>
> The CW does not disable ECMP. Any LSR on the path between ingress and
> egress LER is free to look beyond the MPLS label stack and
> misinterpret the 0x00 0x00 at the start of a control-word as a valid
> MAC that starts 00:00:XX:XX:XX:XX and try to hash on Ethernet headers
> starting directly after the MPLS label stack, and not label stack + 4
> bytes. This is my point. The PWMCW doesn't stop re-ording in all
> cases, but it does in most. So yes, not all devices support EL, but CW
> doesn't stop re-ordering in all cases, so?
>
> > That said, I'm also concerned that because of the existing text in 7432,
> implementations may not be using the CW even for P2P EVPN.
> >
> > And we still don't have a good answer for Muthu's original question. :-)
>
> Sorry my intention is not to send this thread off-topic.
>
> Cheers,
> James.
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Signaling Control Word in EVPN

2018-10-09 Thread James Bensley

On Tue, 9 Oct 2018 at 15:16, Andrew G. Malis  wrote:
>
> James,

Hi Andy,

> It's much harder to mandate use of EL than the CW for several reasons:

I didn't say it should be mandated, but recommended.

> - CW implementation is much more common than EL implementation
> - PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel, 
> rather, they will be multiplexed with other MPLS-based applications that are 
> using the traffic tunnel to reach a common destination. Thus, by using the 
> CW, you can disable ECMP only for those MPLS packets that cannot tolerate 
> reordering.

The CW does not disable ECMP. Any LSR on the path between ingress and
egress LER is free to look beyond the MPLS label stack and
misinterpret the 0x00 0x00 at the start of a control-word as a valid
MAC that starts 00:00:XX:XX:XX:XX and try to hash on Ethernet headers
starting directly after the MPLS label stack, and not label stack + 4
bytes. This is my point. The PWMCW doesn't stop re-ording in all
cases, but it does in most. So yes, not all devices support EL, but CW
doesn't stop re-ordering in all cases, so?

> That said, I'm also concerned that because of the existing text in 7432, 
> implementations may not be using the CW even for P2P EVPN.
>
> And we still don't have a good answer for Muthu's original question. :-)

Sorry my intention is not to send this thread off-topic.

Cheers,
James.

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

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

2018-10-09 Thread Jaikumar Somasundaram

Thanks Mrinmoy.
Response in-lined.

From: Mrinmoy Ghosh (mrghosh) 
Sent: Thursday, October 4, 2018 11:40 PM
To: Jaikumar Somasundaram ; Rabadan, Jorge 
(Nokia - US/Mountain View) ; bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

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

Hi Jaikumar,

Backup failure can happen in multiple forms, Node down, Interface down etc.
There is no DF election timer on ES withdrawal, it should be carved immediately 
in Peering PEs.
[Jai] RFC 7432 does not mention anything about this.

…
  In the case of link or port failure, the affected PE withdraws its
  Ethernet Segment route.  This will re-trigger the service carving
  procedures on all the PEs in the redundancy group.  For PE node
  failure, or upon PE commissioning or decommissioning, the PEs
  re-trigger the service carving.

DF election timer is manly when the ES is coming up (Node up, Interface up etc) 
to specify some.

Thanks,
Mrinmoy

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Jaikumar Somasundaram
Sent: Thursday, October 4, 2018 8:39 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

Yes, new DF will be identified after the new election.
Election process will need to wait for DF election timer period, say 3s or the 
configured timer period.
Until this DF election timer expiry and new DF is identified, the traffic 
towards CE coming to the node this PE
will get dropped. Please let me know if my understanding is right?

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 8:06 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Jai,

The new DF becomes DF because it re-runs DF election.
Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 12:23 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto: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) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto: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. 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

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

2018-10-09 Thread Jaikumar Somasundaram

Thanks Jorge.

I think that this optimization is not mentioned in the RFC 7432.

Section 8.5 of RFC 7432:

  In the case of link or port failure, the affected PE withdraws its
  Ethernet Segment route.  This will re-trigger the service carving
  procedures on all the PEs in the redundancy group.  For PE node
  failure, or upon PE commissioning or decommissioning, the PEs
  re-trigger the service carving.

Section 13.2.1 of RFC 7432:


  - If the PE is not the designated forwarder on any of the ESIs for

 the Ethernet tag, the default behavior is for it to drop the

 packet.

Section 14.1.1 of RFC 7432:


   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.

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Thursday, October 4, 2018 10:11 PM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

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

Hi Jai,

Yes, but see my other email.. if you only have two PEs in the ES, you may 
optimize things.
Thanks.
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 5:39 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

Yes, new DF will be identified after the new election.
Election process will need to wait for DF election timer period, say 3s or the 
configured timer period.
Until this DF election timer expiry and new DF is identified, the traffic 
towards CE coming to the node this PE
will get dropped. Please let me know if my understanding is right?

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 8:06 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Jai,

The new DF becomes DF because it re-runs DF election.
Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 12:23 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto: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) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto: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?

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

2018-10-09 Thread Yutianpeng (Tim)

Hi Jai,
I think draft-ietf-bess-evpn-df-election-framework-03 section-3.1 might help.
Thanks & Regards
Tim

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jaikumar Somasundaram
Sent: 05 October 2018 06:07
To: Rabadan, Jorge (Nokia - US/Mountain View) ; 
bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

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

Thanks Jorge.

I think that this optimization is not mentioned in the RFC 7432.

Section 8.5 of RFC 7432:

  In the case of link or port failure, the affected PE withdraws its
  Ethernet Segment route.  This will re-trigger the service carving
  procedures on all the PEs in the redundancy group.  For PE node
  failure, or upon PE commissioning or decommissioning, the PEs
  re-trigger the service carving.

Section 13.2.1 of RFC 7432:


  - If the PE is not the designated forwarder on any of the ESIs for

 the Ethernet tag, the default behavior is for it to drop the

 packet.

Section 14.1.1 of RFC 7432:


   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.

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 10:11 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jai,

Yes, but see my other email.. if you only have two PEs in the ES, you may 
optimize things.
Thanks.
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 5:39 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

Yes, new DF will be identified after the new election.
Election process will need to wait for DF election timer period, say 3s or the 
configured timer period.
Until this DF election timer expiry and new DF is identified, the traffic 
towards CE coming to the node this PE
will get dropped. Please let me know if my understanding is right?

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 8:06 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Jai,

The new DF becomes DF because it re-runs DF election.
Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 12:23 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto: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) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi

[bess] I-D Action: draft-ietf-bess-mvpn-expl-track-12.txt

2018-10-09 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Explicit Tracking with Wild Card Routes in Multicast 
VPN
Authors : Andrew Dolganow
  Jayant Kotalwar
  Eric C. Rosen
  Zhaohui Zhang
Filename: draft-ietf-bess-mvpn-expl-track-12.txt
Pages   : 18
Date: 2018-10-09

Abstract:
   The MVPN specifications provide procedures to allow a multicast
   ingress node to invoke "explicit tracking" for a multicast flow or
   set of flows, thus learning the egress nodes for that flow or set of
   flows.  However, the specifications are not completely clear about
   how the explicit tracking procedures work in certain scenarios.  This
   document provides the necessary clarifications.  It also specifies a
   new, optimized explicit tracking procedure.  This new procedure
   allows an ingress node, by sending a single message, to request
   explicit tracking of each of a set of flows, where the set of flows
   is specified using a wildcard mechanism.  This document updates RFCs
   6514, 6625, and 7524.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-12
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-12


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/

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

[bess] draft-ietf-bess-mvpn-msdp-sa-interoperation

2018-10-09 Thread Jeffrey (Zhaohui) Zhang

Hi,

The draft had some good discussions prior to its adoption and we believe we 
have resolved issues/comments raised at that time.
A few months ago Hejia did a RtgDir Early review, and a -01 revision was posted 
to address the comments 
(https://mailarchive.ietf.org/arch/msg/bess/sZmyDbMVznyH1vFxEAw2FIyNOHk).

This is a relatively simple and straightforward feature but important to 
simplify practical deployments. There is at least one commercial implementation 
already.
If you have further comments/suggestions, please bring them forward so that we 
as a WG can actively discuss and progress the work.

Thanks!
Jeffrey

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

Re: [bess] Signaling Control Word in EVPN

Re: [bess] Signaling Control Word in EVPN

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

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

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

[bess] I-D Action: draft-ietf-bess-mvpn-expl-track-12.txt

[bess] draft-ietf-bess-mvpn-msdp-sa-interoperation

7 matches

Site Navigation

Mail list logo

Footer information