Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

"Yu Tianpeng" <> Fri, 11 January 2019 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25E6E130E93 for <>; Fri, 11 Jan 2019 13:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.457
X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JGPNOd39xFqw for <>; Fri, 11 Jan 2019 13:44:49 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BC21130E72 for <>; Fri, 11 Jan 2019 13:44:48 -0800 (PST)
Received: by with SMTP id q18so16680350wrx.9 for <>; Fri, 11 Jan 2019 13:44:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:content-language :thread-index; bh=zkUm/JoSs2HPo3Hp51ZFoY2BAiwex0OAyChkdFCPwnM=; b=IhthZ3LAaGMpPAVkLlNA207aYk6yF1ujX+NmE+eTU0kiAOHCChlYmkpyYhgbKLaqAn oEadXkV2J6YpU+EcglIN8oMYJpxDTkRqJ0N2LrcZYGEBfSLF1b/Ua9eq+g0Pe188l4DE Y1TB8yG7/G2p128K3LdvP55564B4kKlYse8xBqhTCpHjQH4FYIh1aVxOIzyJZNYaxpKS mC4k0Z4/YmzSnF9H/HrWdM+6qC4/A4L6tR0Bhs+0gD99nqDRN5iqPFubKeFfhcfPkLjz MUv7KK+JONYcjGrzgfqyGeel27WWPrksiV0gn70k0JtMQAbCE/Mjt0ihhJaAR6vBNyXn TNyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-language:thread-index; bh=zkUm/JoSs2HPo3Hp51ZFoY2BAiwex0OAyChkdFCPwnM=; b=l3MIUZioDGTtT8sSELAG+5Pu49EBV+llHdaYB9Fnybask3SoYiH1VKA6WH9KxD21L9 XOSil/XEF0Rb9cfqWQX9n7p5qBlsLLFWCMz1j6YlJkmv7lj48Gz7mWO1Zh7GLWtvaJ2C ozxYsEcHYJaBdBWFgIClRmDDkTFJ2BU2OETpgIdazzEVrQeTus4ZH+lABwTwOOfmuqRx C4jitD4RZFRe/FZQE3aVjdYUX1/gw1kyvKNA3R0kBUeoMx9zmo1zx2/xhssx9F2+OnbM Rij0nUyUvV83Fm1ZcbOXZzvCHL0Ab2bcegX0Y4Sab7lAUfq6zaWjU30S3V58Vr77FNbo T5IQ==
X-Gm-Message-State: AJcUukcP3uOa7VViDZkvR4AI7ipjEgvvUifUVvzYcR3ov7NV/zk46Lle fjRO6gG0CLMU1MEtPSwO/WFRcN2G
X-Google-Smtp-Source: ALg8bN6k+mxfG7qfhns5/7Mm/6Dx1ZC4n9YHQJ52JD7JzMxZy5Mr1hXSz4Uvf3AEJuw9FAX+Vp5PBQ==
X-Received: by 2002:a5d:6889:: with SMTP id h9mr14940944wru.222.1547243086362; Fri, 11 Jan 2019 13:44:46 -0800 (PST)
Received: from Yct201812100136 ( []) by with ESMTPSA id u204sm33018525wmu.30.2019. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Jan 2019 13:44:45 -0800 (PST)
From: Yu Tianpeng <>
To: "'Ali Sajassi (sajassi)'" <>,
Date: Fri, 11 Jan 2019 21:44:43 +0800
Message-ID: <000a01d4a9b3$cfb14b50$6f13e1f0$>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01D4A9F6.DDD91F30"
X-Mailer: Microsoft Outlook 15.0
Content-Language: zh-cn
Thread-Index: AdSpqC3Rs/24xE92TBuP4GQYJuRkNw==
X-MS-TNEF-Correlator: 000000004824A9C0DC3C6941BEA0158A5294FB100700C3B68E10F77511CEB4CD00AA00BBB6E600000000000D000009BE70CC7F27214C88DF9E296610BFBB0000000010010000
Archived-At: <>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Jan 2019 21:44:56 -0000

Hi Ali and Stephane,

Sorry again for comment too many times at this stage. I understand LC
officially ended (but failed), thanks for Ali’s patient. 

If we check the document we still have many changes in recent days and part
of them are real mistakes not just optimization right? 


Ali, please read comment 5 again.  TBH for the others I don’t worry too
much as they are wording optimization to avoid confusion. 

Comments below inline.


Thanks for understanding.




发件人: Ali Sajassi (sajassi) [] 
发送时间: 2019年1月12日 3:50
收件人: Yu Tianpeng;
主题: Re: [bess] WGLC, IPR and implementation poll for


Hi Stephane,


The WGLC for this draft was ended on Dec/17. Yu sent his 1st batch of
editorial comments about 3 weeks after WGLC ended on 1/7 and I addressed
them. He then generated a new set which I addressed them as well. He has now
generated the third set which are mostly invalid and indicative of lack of
understanding of RFC 7623 which is prerequisite to this draft. I am rejected
this third set not because he keeps generating new set but because of
invalidity of them which I explain in the text below. I want to encourage
participation of new incomers like Yu but they should also take time to
understand both IETF procedures on WG calls and also on RFCs related to a
draft before keep generating comments. 


From: Yu Tianpeng < <>>
Date: Thursday, January 10, 2019 at 10:29 AM
To: Cisco Employee < <>>, "
< <>>
Cc: " <>"
< <>>, "
<>" < <>>
Subject: Re: [bess] WGLC, IPR and implementation poll for


Thanks a lot Ali for the 03 version. This version fixs all comments raised
before and also some others e.g. df election criteria.

But unfortuatelly I have more comments, sorry abount that...
Comment 5 is a major one, others are mainly wording and typo...

1. Related with 5.1 to 5.4, I suggest rename title as below:
5.1 Single vES Failure Handling in multi-homed EVPN
5.2 Single vES Failure Handling in multi-homed PBB-EVPN
5.3 Multiple vES Failure Handling in multi-homed EVPN
5.4 Multiple vES Failure Handling in multi-homed PBB-EVPN
1) procedure described should applies to multi-homed active-active, we
should not say single-active, suggest use multi-homed instead
2) multiple vES failure can be caused by ENNI port/link failure, and EVC/PW
failure (even failure of one EVC fails can lead to failure of multiple vES),
but for EVPN, actually failure procedure are same.
Correspondingly some words in the content might need to be changed if we
decide to change the title.

REJECTED: The current titles are correct. Please read RFC 7623. If you read
it, you will see that All-Active multi-homing does NOT require MAC flushing
!! The sections are about Single-Active vES and NOT single failure in vES.

[Tim]: PBB all active does not require, But EVPN 7432 requires a withdraw
of ES or vES in this document. vES actually should follow 7432 process if
only one fails.

2. 5.1 need changes from "CMAC" to "MAC". Probablly "Ethernet Segment" to
"vES" also will be better.

REJECTED: The current text is correct. The first paragraph is about
Ethernet Segment and not vES. The second paragraph is about vES and EVC !!

[Tim]: Title of 5.1 is EVPN 7432 related not PBB-EVPN, why we mention CMAC?
I would say the description inside is confusing. Is it describing PBB-EVPN


3. Some wording changes are needed in 5.1
To be precise, there is no
MAC flush per-se if there is only one backup PE for a given ES -
i.e., only an update of the forwarding entries per backup-path
procedure in [RFC 7432].
To be precise, there is no per MAC basis flush, only an update of the
forwarding entries and delete the failure vES in MAC nexthop table based on
procedure in the section 8.2 of [RFC 7432].

Or at least we need to fix "per-se", anyhow it seems to be a typo..

“per se” is and adverb. 


4. Section 5.3
Router's MAC Extended Community is newly added in version-03. Before my
understanding was I should always use type 3 ESI (Port MAC address +
Discriminator) in EAD.
So the correct understanding should be: I can use any type of ESI in AD
stage, and I need to include Router's MAC Extended Community with port MAC
along with EAD, but type 3 has to be used in MASS-withdraw based on -03
Is my understanding correct?

REJECTED: We are talking about two different things. There is a vESI for
vES and there is ESI for ES associated with ENNI. Bullet 1 in section 5.3
talks about when advertising vES you need to color them and the way to color
them is to use Router’s MAC EC. vESI can be of any format. Bullet 2 talks
about when withdrawing ES associated with the ENNI, then you advertise the
withdraw message with this special ESI.

[Tim]: This is not a comment, just a question. My fault for description not
being clear.  I am not asking to change anything,

Till 03 version, EVPN Router's MAC Extended Community is added here. Before
MAC extended community is only mentioned in PBB-EVPN related procedure, but
in EVPN 7432 related (5.1, 5.3) this community is not mentioned. 

So my understanding based  on 02 version is not correct and updated by 03

5. Still section 5.3
For this part I have a concern on the mechanism to be used in PW or when
ENNI is a LAG.
When system terminate PWs and start EVPN, the ENNI will be a logical
"virtual" interface in the system and not physical interface.
This logical interface will use system mac (some people call it bridge
mac), and it will be shared by all ENNIs in the same device.
If I fill in the mass-withdraw ESI with this MAC+0xFFFFFF it will withdraw
all ENNIs on this PE even those not failed.
Same logic, when ENNI is LAG, also system MAC used.
So based on my understanding, this mechanism only works if: EVC is
terminated directly on physical ENNI.
The mechanism will not work if: EVC is terminated on LAG or PW terminated
and ENNI is logical interface.
Or we plan mac address of all logical ENNIs manually:)...

REJECTED: For logical interface such as RSVP-TE tunnel where it can
aggregate many PWs, then the tunnel can be considered as ENNI and each PW
can be considered as an EVC associated with a vES.

[Tim]: Please read the comment, the answer is not answering the concern. 

The question is if ENNI is not a physical interface, the MAC address is
system MAC and shared by multiple ENNIs. System MAC cannot be used in the
procedure described in section 5.3 (bullet 2).


6. Small Nits in section 3.4
vc-type VLAN could lead to misunderstanding as meaning of this word differs
between vendors. Appreciate if we can use language in RFC4448 (e.g. Raw




Thanks & Regards,


On Thu, 10 Jan 2019, 06:17 Ali Sajassi (sajassi) <
<>  wrote:



From: Yu Tianpeng < <>>
Date: Wednesday, January 9, 2019 at 4:03 AM
To: Cisco Employee < <>>
Cc: " <>"
< <>>, "
<>" < <>>
Subject: Re: [bess] WGLC, IPR and implementation poll for


Thanks a lot Ali for the updating. 

Looks fine for me apart from one point. 

Correct me if I am wrong for what mentioned below.

This document aims to enable capability of evpn to be used on ENNI. But
ENNI also have EVPL, ELAN and ETREE services.  This document have a
brilliant solution, but overall current document only mentions usage in
ELAN, so the question is how about ETREE and VPWS? As the solution in this
document is vES based, I believe it should work for ETREE and VPWS without
much extra considerations.  So if authors agree, I prefer to cover this in
the current document. It is also fine for me if authors' choice is out of
scope and prefer to cover other scenarios in a separate document. 


I have already added VPWS. However, there is no point to list every EVPN
solution in this document or else we have to list not just evpn-etree but
evpn-overlay, evpn-irb, evpn-mcast, evpn-fxc, etc. 


By the way another nits..

Sub type in figure 6 is not consistent with description above. I got lost
on this as previous version was still 0x04.. so if 0x07 is the correct one
please fix the value in the figure


That has already been corrected.





Thanks a lot.





On Wed, 9 Jan 2019, 00:31 Mankamana Mishra (mankamis) <
<>  wrote:

Thanks ali. I took look at the diff, it looks ok to me to move forward. 






From: BESS < <>> on
behalf of "Ali Sajassi (sajassi)" < <>>
Date: Tuesday, January 8, 2019 at 3:17 PM
To: Tim < <>>, "
<>" <
<>>, "
<>" < <>>
Subject: Re: [bess] WGLC, IPR and implementation poll for



Tim, Mankamana,


The rev02 of the draft has the updates to address your latest comments.





From: BESS < <>> on
behalf of Tim < <>>
Date: Monday, January 7, 2019 at 2:53 PM
To: " <>"
< <>>, "
<>" < <>>
Subject: Re: [bess] WGLC, IPR and implementation poll for



Support this work as an individual. This document is a great and elegant
step for EVPN towards SP network.

Some small comments by the way:

1. Figure 2 shows the scope of EVPN network but the other figures in the
document not. Please kindly update, then it is more readable.

2. There are 2 Figure 2

3. Document is lack of mention on E-Tree, it should work without any extra
consideration right?

4. Please fix format issue in section 8 and update TBD in section 9.




On 2018/12/3 18:43,
<>  wrote:

Hello Working Group,


This email starts a two-week Working Group Last Call on
draft-ietf-bess-evpn-virtual-eth-segment [1]


This poll runs until *the 17th of December*.


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. The Document won't progress without answers from
all the Authors and Contributors.


There is currently no IPR disclosed.  


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.


We are also polling for any existing implementation as per [2]. 


    Thank you,

    Stephane & Matthew







Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.


BESS mailing list <>