Re: [bess] CW in EVPN: Was Signaling Control Word in EVPN

[Yutianpeng (Tim)]

Hi,
Some comments below.
Regards,
Tim
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of James Bensley
Sent: 29 October 2018 13:34
To: bess@ietf.org; p...@ietf.org
Subject: Re: [bess] CW in EVPN: Was Signaling Control Word in EVPN

On Tue, 23 Oct 2018 at 09:28, Alexander Vainshtein 
 wrote:
>
> James,
>
> I am adding PALS WG to the list of addressees because, AFAIK, the PW CW is 
> defined in this WG.
>
>
>
> I think that the really observed problem with incorrect ECMP behavior exists, 
> but it is different from your description in your earlier email:
>
>
>
> 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.
>
>
>
> I have not seen (or heard about) such behavior in any deployed networks.
>
[Tim]: This behavior exists on some devices, but they should at least ignore 
0x0 MAC.
>
> However, I am aware of some modern forwarding chipsets that (correctly) treat 
> the ‘’ in the first nibble of the payload of a labeled packet (i.e., 
> immediately following the bottom of the label stack) as the indication of a 
> 32-bit PW control word but (incorrectly), consider this as a CW of an 
> Ethernet PW (as if no other PWs exist!) and try to hash on the presumed MAC 
> addresses, Ethertype etc.  Such behavior is really deadly for, say TDM PWs 
> that, AFAIK, are still widely deployed in many places.
[Tim]: Yes, this does exist, at least ever :), but this is a behavior not 
compliance with RFC and should be corrected. Chipset with such capabilities is 
usually programmable and should have the capability to fix the limit, otherwise 
will be a disaster for pretending to be intelligent. 
>

Hi Sasha,

Well in either case we have both provided different examples of when the PWMCW 
doesn't prevent reordering when ECMP is present in the PSN.
Perhaps I need to actually step back a bit here and ask a different question, 
to further understand the non-technical problem first.

What is the scope/remit of the WG in this scenario? To be clear on what I mean 
by this, the PWMCW is a flawed method for preventing reordering when ECMP is 
present (see our two examples above). It also doesn't add any entropy to 
improve ECMP when ECMP is required. Entropy labels help to prevent reordering 
and help to add entropy, despite these technical benefits but they may have 
other non-technical disadvantages. So what is the WGs remit with recommending 
one technology over another?

In this specific case, is it:

Option 1. The WG's remit is to phase out or discourage flawed technologies if a 
superior one exists, so it should look to deprecate CWs because ELs are 
superior from a purely technical view?
Option 2. The WG's remit is to support as many technologies as possible, so it 
shouldn't look to deprecate CWs because ELs may have other non-technical draw 
backs?
Option 3. The WG's remit is to remain neutral on the subject of CWs vs other 
methods, and simply ensure that all drafts follow the correct due diligence 
process regardless of whether one technology is technically "better" than 
another?
Option 4. The WG's remit is something else?


[Tim]: My opinion is: 
Control word is proven technology for years and has been deployed a lot. I 
cannot find a reason we should abandon it. ELs can be better but it is also 
difficult to achieve.
Many of the chipsets nowadays are still not capable to implement ELs. I believe 
both techniques will exit for a long period of time.

Cheers,
James.

___
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] A question regarding draft-wang-bess-evepn-control-word

[Yutianpeng (Tim)]

Hi Sasha,
Thanks a lot for your advice.
I agree with you that CW is not mandatory for all traffic, mainly unicast. This 
draft focuses on CW capability advertisement and is applicable to traffic needs 
CW processing.  So far BUM should be not relevant to this draft. (Multicast 
might need CW potentially we realize recently, but we will visit this topic 
later.)
Some clarification on my proposal:
I believe we need a mechanism of negotiation on CW capabilities in EVPN ELAN. 
If you check PW or EVPN VPWS there is a clear procedure on negotiation between 
two ends.
Refer to: https://tools.ietf.org/html/rfc4447#section-6 and Appendix 
A<https://tools.ietf.org/html/rfc4447#appendix-A>
But as EVPN is MP2MP, in case of PE CW behavior can be different between PEs as 
there is no negotiation at all at the moment.
So this draft introduces CW capability which at least allows PEs within EVI 
knows the capability of each other. It also defines behavior after receiving CW 
capabilities.
What I proposed is the behavior in case CW capabilities across PEs are 
different. I mentioned a simple way of tearing down or isolate CW disabled PEs 
and raise an alarm, a bit similar to PW. The draft proposes a graceful way that 
traffic can be forwarded with a label advertised together with CW capability, 
such that egress PE can indicate CW via the label on the forwarding plane.
Happy for further discussion on this as CW of EVPN topic has been raised couple 
of times recently.
Thanks & Regards,
Tim

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: 24 October 2018 09:39
To: Yutianpeng (Tim) 
Cc: draft-wang-bess-evpn-control-word.auth...@ietf.org; bess@ietf.org; 
Wanghaibo (Rainsword) 
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Tim,
Lots of thanks for sharing your views.

Unfortunately, I doubt the approach that you propose: always use or do not use 
CW in the same EVI.

The problem, as I see it is that known unicast and BUM traffic may be handled 
differently when it comes to EVPN encapsulation:

1.   Section 18 of RFC 7432 explicitly states that “When sending 
EVPN-encapsulated packets over a P2MP LSP or P2P LSP, then the control word 
SHOULD NOT be used”

a.   This recommendation is quite reasonable because the LSPs in question 
are not affected by ECMP, so there is no need to use the CW to prevent 
ECMP-cause reordering

b.  It is quite possible to P2MP LSPs as the P-tunneling technology 
delivery of BUM traffic in EVPN while using MP2P LSPs for carrying known 
unicast traffic

c.   The bottom line: RFC 7432 defines the  scenario when the CW SHOULD be 
used in the EVPN encapsulation of the known unicast traffic but SHOULD NOT be 
used in the EVPN encapsulation of BUM traffic as valid

2.   I am aware (this information is publicly available) of at least one 
deployed EVPN implementation that:

a.   By default includes the CW in the EVPN encapsulation of known unicast 
traffic (this default behavior can be disabled by explicit configuration)

b.  Does not include the CW in the EVPN encapsulation of BUM traffic, 
presumably due to limitations imposed by the forwarding HW.

c.   The bottom line: inconsistent usage of CW in the EVPN encapsulation 
within the same EVI (with differences between known unicast and BUM traffic) is 
already a fact on the ground (at least, to some extent).

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Yutianpeng (Tim) [mailto:yutianp...@huawei.com]
Sent: Tuesday, October 23, 2018 5:48 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Cc: 
draft-wang-bess-evpn-control-word.auth...@ietf.org<mailto:draft-wang-bess-evpn-control-word.auth...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi Sasha,
I am also thinking of this recently but haven’t talked with author yet.
What was in my mind the solution is actually simple: directly tear down (part 
of) the mac-VRF or EVI directly if CW capabilities not consistent, considering 
behavior in one EVI should keep consistent (personally believe).
I might tend to the mechanism as below:
If router A has CW capabilities and receive type 1 or type 2 routes without CW, 
then A should drop these routes and report an alarm.
If router A does not has CW capabilities and receive type 1 or type 2 routes 
with CW, then A should drop these routes and report an alarm.
I believe the behavior within EVI or Mac-VRF should keep consistent, otherwise, 
more questions will pop out.
Considering if a service is sensitive to packet misordering and it is ELAN, I 
tend to keep behavior within this ELAN consistent.
There could also be other problems with this approach, just share an idea so 
far open the discussion.
Reg

Re: [bess] A question regarding draft-wang-bess-evepn-control-word

[Yutianpeng (Tim)]

Hi Sasha,
I am also thinking of this recently but haven’t talked with author yet.
What was in my mind the solution is actually simple: directly tear down (part 
of) the mac-VRF or EVI directly if CW capabilities not consistent, considering 
behavior in one EVI should keep consistent (personally believe).
I might tend to the mechanism as below:
If router A has CW capabilities and receive type 1 or type 2 routes without CW, 
then A should drop these routes and report an alarm.
If router A does not has CW capabilities and receive type 1 or type 2 routes 
with CW, then A should drop these routes and report an alarm.
I believe the behavior within EVI or Mac-VRF should keep consistent, otherwise, 
more questions will pop out.
Considering if a service is sensitive to packet misordering and it is ELAN, I 
tend to keep behavior within this ELAN consistent.
There could also be other problems with this approach, just share an idea so 
far open the discussion.
Regards, and lots of thanks in advance,
Tim

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: 23 October 2018 14:42
To: Wanghaibo (Rainsword) 
Cc: draft-wang-bess-evpn-control-word.auth...@ietf.org; bess@ietf.org
Subject: Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Dear Haibo,
Again,
Lots of thanks for a prompt response.

My reading of your response is as following:

1.   All egress PEs can receive EVPN-encapsulated packets without the CW

2.   All ingress PEs can sent EVPN-encapsulated packets without the CW

3.   An egress PE that can receive EVPN-encapsulated packets with the CW in 
the EVPN encapsulation,  must add the appropriate NH Capability attribute that 
indicates the CW-indicating label value (explicitly or implicitly) to all 
relevant EVPN routes.  This includes:

a.   Per-EVI Ethernet A-D route (EVPN Route Type 1). In this case the CWI 
label would follow the label advertised in the NLRI of this route

b.  MAC/IP Advertisement route (EVPN Type 2 route). In this case the CWI 
label would follow the label advertised in the NLRI as Label1, it would not be 
relevant for packets that are encapsulated using Label2 (used with the 
Symmetric EVPN IRB).

4.   An ingress PE that has received an EVPN route with the CW capability 
attribute wand that can support usage of CW in the EVPN encapsulation, will 
insert both the CWI advertised in the CW capability attribute, and the CW in 
the EVPN packets it sends to the corresponding egress PE.  If it does not 
support usage of CW in the encapsulation, it will not insert this label.

Is this understanding correct?

If yes, I still have a couple of questions:

1.   Suppose that you use ingress replication (IR) to deliver BUM traffic 
across EVPN. The Ingress Replication label would be advertised in the PTA 
attribute of the Inclusive Multicast Ethernet Tag Route (EVPN Type 3 route); it 
will not be part of the NLRI. Do you expect the same logic to be used with 
regard to CW capabilities and CWI label advertisement applied also to these 
routes?

2.   Per-ES Ethernet A-D Routes are advertised with the ECI expended 
Community that carries within the so-called ESI label. This label is included 
the EVPN encapsulation of BUM packets sent to the PE that is attached to the 
same multi-homed ES from which the original ES packet has been received. Do you 
expect the same logic to be used with regard to CW capabilities and CWI label 
advertisement applied also to these routes with the CWI label following the ESI 
label in the EVPN encapsulation of BUM packets?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: Wanghaibo (Rainsword) [mailto:rainsword.w...@huawei.com]
Sent: Tuesday, October 23, 2018 2:34 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>
Cc: bess@ietf.org; 
draft-wang-bess-evpn-control-word.auth...@ietf.org
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi Alexander,

The solution here is to carry the next hop capability attribute when the route 
is advertised. The capability carried here is the control word capability.
The specific format of the next hop capability can be referred to the draft.: 

 +--+
 | Capability Code (2 octets)   |
 +--+
 | Capability Length (2 octets) |
 +--+
 | Capability Value (variable)  |
 ~  ~
 +--+
For the control word capability , it may encode as :
 +--+
 | CW Capabality Type 

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

[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