Re: [bess] Second WG Last Call on draft-ietf-bess-evpn-proxy-arp-nd-06

[Yu Tianpeng]

Dear WG,
support
this is useful optimization mechanism and has couple of known
implementations and well documented.
Thanks,
Tim


On Fri, 7 Jun 2019, 10:07 Bocci, Matthew (Nokia - GB), <
matthew.bo...@nokia.com> wrote:

> WG
>
>
>
> We ran a working group last call on this draft in August 2018. Although we
> had an Ops Area review, we did not get a lot of responses from participants
> who were not already authors of the draft. We are therefore running another
> working group last call on draft-ietf-bess-evpn-proxy-arp-nd-06.
>
>
>
> Please indicate to the list if you have read the draft and support its
> publication as an RFC. Please also indicate to the list if you have read
> the draft and do not support its publication.
>
>
>
> Please also send any other last call comments to the BESS list.
>
>
>
> This last call ends on Friday 21st June 2019.
>
>
>
> Regards
>
>
>
> Matthew and Stephane
> ___
> 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

[bess] Comments on draft-ietf-bess-evpn-yang-07

[Yu Tianpeng]

Hi authors,
Thanks a lot for the -07 version of EVPN yang, which fixes many points ever
raised in the mail list also some we did not notice. This version moves
this document a big step forward.
Thanks for the presentation and update in 104 also.

Related with the  P-tunnel been discussed before, I think there are two
points to fix:
1. Current version lacks a definition of P-tunnel type in inclusive
multicast ethernet tag route (for route query only, read only), raised by
Sasha initially.
It may be fixed in this way, Import the "typedef p-tunnel" defined in
draft-ietf-bess-mvpn-yang-01, and add a leaf called tunnel-type in
inclusive multicast ethernet tag route.
2. Related with the place to configure IR or P2MP, since P-tunnel is a
concept per EVI basis, I would suggest moving this into evpn-instances.
And this leaf is read+write.

And I had a line-by-line read again before LC starts, and there are some
comments as below (Probably a long list.. I hope most of them not issues or
can be fixed easily).

Appreciate if the authors could have a look.

Thanks in advance.
Regards,
Tim

##

ethernet-segment yang

1. the key of "container ethernet-segments" is "name", should not it be
ESI?
I have no clue how to fill the name field TBH, does it mean "interface"? If
so it should be read-only I suppose.  If no, where is the mount point to
interface...

2. service-type, what does it mean?? Does it mean vlan-based, vlan-bundle,
vlan-aware-bundle? If so why there is "vpws-vlan-aware" in evpn yang..

3. related with leaf "ac-or-pw"
I would suggest to use evc instead of ac as it is quite confusing. Also in
vES draft it is using evc.
And for ac, it is the interface that bound to the evi, right? What if the
es is not ves, can I fill in the interface with physical interface? If no,
we may need another leaf indicating the interface for ES.


4. vlan in leaf df, please add range restriction and use uint16. This is
aligned with many yang modules already standardised

5. leaf esi-label, it should have been covered by evpn route in evpn yang
right?  this is the label in ESI Label Extended Community right?
And if I look at evpn yang, the Extended community is defined to be a raw
string.
Also, I cannot see e-tree label.. and I cannot find the bit saying this ES
is leaf of etree or not..
TBH I have concerns on if a raw string is a proper way to reflect all
extended communities

6. leaf ead-evi-route: similarly, this is Aliasing right? Is es or evpn
yang the better place to put this function?

7. In es yang: what is the meaning of member, which is an IP address?  Is
it the router-id of the device? Please add some description here.


evpn.yang
1. Counters I would suggest to use counter64 instead of counter 32,
counter32 is too likely to get overflowed.

2. Control word function defined in 7432 is not included (VPWS one should
be fine as it is mounted to l2vpn pw yang, i suppose).

3. leaf vpws-vlan-aware looks abrupt to me in evpn yang... what is it used
for?

4. leaf bestpath in path-detail-grp in evpn yang should use boolean instead
of empty. I suppose?

5. related with statistics, this is a sum of the counter of all interfaces
bound to the corresponding EVI right? Please add a bit description on this
if possible..

6. Related with the mount point of EVPN VPWS, only a container called
"evpn-pw" is defined? I am not sure how many functions being missed in EVPN
VPWS tbh... In my mind so far:
no EAD route query,
no statistics
rd-rt info..?
Also we may need to exclude some leaf from pw yang for evpn vpws
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

[Yu Tianpeng]

Hi Sasha,
If you read the beginning of even yang, it has a common leaf which
indicating it is IR or P2MP. But it is globally not per EVI.
So actually I also have a comment here I may forgot to mention in previous
email is that this common leaf should be per EVI basis not globally.
If this info should be included in route leaf, the common leaf actually can
be deleted I believe.
So basically I support what you said.

Hi author,
Thanks for the new version which fixes  a lot.
But I still have some concerns on the current version.
I will try put major ones down later.

Here just quick query on the usage of counter32 in statistics, isn't it
very likely to get full in short time?  If you check interface-yang it
always use counter64. If I calculate correctly, with 1mbps traffic
counter32 will rotate in about 1 hour. Or I miss sth?

Thanks in advance.
Regards
Tim



On Wed, 13 Mar 2019, 06:47 Alexander Vainshtein, <
alexander.vainsht...@ecitele.com> wrote:

> Hi all,
> I am now reading the draft, and I see that it is a substantial improvement
> over the earlier versions.
>
> At the same time I have a question regarding the definition of Type 3
> (Inclusive Multicast Ethernet Tag) EVPN route in this (and previous)
> versions.
>
> The YANG definition of this route  runs as following:
> 
>  list inclusive-multicast-ethernet-tag-route {
>uses route-rd-rt-grp;
>leaf originator-ip-prefix {
>  type inet:ip-prefix;
>  description "originator-ip-prefix";
>}
>list path {
>  uses next-hop-label-grp;
>  uses path-detail-grp;
>  description "path";
>}
>description "inclusive-multicast-ethernet-tag-route";
> 
>
> This definition matches the definition of the NRLI of this route in
> Section 7.3 of RFC 7432. But it seems to miss the requirement (stated in
> Section 11.2 of RFC 7432) that this route MUST carry an PMSI Tunnel Type
> Attribute (a.k.a. PTA) as defined in RFC 6514.
>
> The draft also defines a Boolean attribute underlay-multicast of an EVPN
> instance, but it does not explain what this means and how it is used. My
> guess )FWIW) is that this attribute differentiates between EVPN instances
> that use ingress replication and EVPN instances that use P2MP LSPs to
> deliver BUM traffic. But it does not help to identify specific  technology
> used for setting up P2MP LSPs, and does not allow the user to see the
> labels advertised in the PTA.
>
> Did I miss something substantial here?
>
> Regards, and lots of thanks in advance,
> Sasha
>
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>
> -Original Message-
> From: BESS  On Behalf Of internet-dra...@ietf.org
> Sent: Monday, March 11, 2019 9:21 PM
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: [bess] I-D Action: draft-ietf-bess-evpn-yang-07.txt
>
>
> 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   : Yang Data Model for EVPN
> Authors : Patrice Brissette
>   Himanshu Shah
>   Iftekar Hussain
>   Kishore Tiruveedhula
>   Jorge Rabadan
> Filename: draft-ietf-bess-evpn-yang-07.txt
> Pages   : 28
> Date: 2019-03-11
>
> Abstract:
>This document describes a YANG data model for Ethernet VPN services.
>The model is agnostic of the underlay. It apply to MPLS as well as to
>VxLAN encapsulation. The model is also agnostic of the services
>including E-LAN, E-LINE and E-TREE services. This document mainly
>focuses on EVPN and Ethernet-Segment instance framework.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-yang/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-07
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-yang-07
>
>
> 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
>
> ___
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, 

Re: [bess] Review on draft-ietf-bess-evpn-yang-06

[Yu Tianpeng]

Hi Luc and Sasha,
Thanks both for the reply.
Will wait for the new version.
Regards,
Tim


On Sun, 3 Mar 2019, 15:39 Alexander Vainshtein, <
alexander.vainsht...@ecitele.com> wrote:

> Luc hi,
>
> Lots of thanks for a prompt response.
>
>
>
> Will be waiting for the new version of the draft.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* Luc Andre Burdet (lburdet) 
> *Sent:* Sunday, March 3, 2019 3:02 PM
> *To:* Alexander Vainshtein ; Yu
> Tianpeng ;
> draft-ietf-bess-evpn-yang.auth...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Review on draft-ietf-bess-evpn-yang-06
>
>
>
> Hi Sasha, Tim,
>
>
>
> Apologies for not sending a response to your prior email; Your comments
> were noted and intend to update the draft this week.
>
>
>
> Thanks,
>
> Luc André
>
>
>
>
>
> [image:
> http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]
>
> *Luc André Burdet*
>
> lbur...@cisco.com
>
> Tel: *+1 613 254 4814*
>
> Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
>
> Cisco.com <http://www.cisco.com/web/CA/>
>
>
>
>
>
> *From: *BESS  on behalf of Alexander Vainshtein <
> alexander.vainsht...@ecitele.com>
> *Date: *Sunday, March 3, 2019 at 05:46
> *To: *Yu Tianpeng , "
> draft-ietf-bess-evpn-yang.auth...@ietf.org" <
> draft-ietf-bess-evpn-yang.auth...@ietf.org>
> *Cc: *"bess@ietf.org" 
> *Subject: *Re: [bess] Review on draft-ietf-bess-evpn-yang-06
>
>
>
> Dear all,
>
> I concur with Tim’s comment regarding representation of ESI in
> draft-ietf-bess-evpn-yang-06.
>
>
>
> I have raised similar concerns in an email
> <https://mailarchive.ietf.org/arch/msg/bess/HfPveilbdp5iufQYh5pu9KSf4Ug>
> to the authors of the draft and to the WG  last August (when the draft was
> still at its -05 version).
>
> Unfortunately, I did not receive any response, nor were my concerns
> addresses in the -06 version of the draft.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* BESS  *On Behalf Of *Yu Tianpeng
> *Sent:* Saturday, March 2, 2019 9:31 PM
> *To:* draft-ietf-bess-evpn-yang.auth...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* [bess] Review on draft-ietf-bess-evpn-yang-06
>
>
>
> Dear authors and WG,
>
> I had a review on draft-ietf-bess-evpn-yang-06.
>
> This draft covers most of the evpn/vpws scenarios, but there are some
> points I would like to discuss.
>
>
>
> For small points that do not impact the architecture of the yang data
> model, I have made changes in a new yang file directly (attached), which
> will be easier to understand.
>
> Also, some comments related to the structure of the data model in the
> final.
>
> Appreciate authors and WG can have a review on comments and proposed
> changes below.
>
> Thanks in advance.
>
> Regards,
>
> Tim
>
>
> =
>
> Changes:
>
> ietf-ethernet-segment.yang
>
> 1. esid-type defined. current uint32 cannot cover 10 octs ESI. We can
> either use a string with a regex or uint64 with a range. in the attachment
> is the regex.
>
> 2. change key to esi instead of "name", the name looks like a string or a
> description to me, cannot be used as the key.
>
> 3. add new leaf "interface" to indicate which ESI applied to which
> interface.
>
> 4. BGP parameters are deleted, I don't think RD RT are concepts related
> with ES. I have put a new leaf es-list in the EVPN yang data model
> providing links between ES and EVPN yang
>
> 5. change of VLAN type to unit16 with range limit
>
>
>
> ietf-evpn.yang
>
> 1. evpn label mode function added
>
> 2. re-write RD RT part as rt-types:vpn-route-targets is a list type
> already, an extra level of list definition in EVPN is not needed anymore.
>
> 3. ES list leaf added. This leaf provides a list indicating ESs bound to
> the EVPN instance.
>
> 4. control word and MTU added
>
> 5. statistics part re-structure.
>
> 6. change the counter type from uint32 to counter64 to avoid overflow.
>
> 7. interface type leaf added, the previous vpws-vlan-aware deleted.
> reason: all interface type should be covered across EVPN and VPWS
>
>
>
> General comments:
>
> 1. In EVPN yang, I would suggest to re-structu

Re: [bess] Request for version update of draft-ietf-bess-evpn-yang

[Yu Tianpeng]

Hi,
Haven't got time to read through but had a quick look on what is newly
added, there are couple of issues:
1. 7432 clearly defines usage of control word usage, cw is not sth
dedicated to vpws I have to point out.
2. Type of control word should be boolean instead of empty.

Another one is I don't understand the meaning of newly added concext.
Appreciate to clarify.
Thanks
Tim


On Thu, 21 Feb 2019, 13:28 Lavanya Sundarraj, <
lavanya.sundar...@ericsson.com> wrote:

> Hi,
>
>
>
> Please find updated  EVPN yang model with evpn-pw attributes in the
> attachment.
>
> This draft is to introduce EVPN-VPWS attributes :
>
> o   Control-word
>
> o   MTU
>
> o   EVPN Instance Context
>
>
>
> The new changes added in the existing EVPN yang model are highlighted.
>
>
>
> Could you please review this draft and send your valuable comments.
>
>
>
> Regards,
>
> Lavanya Sundarraj.
> ___
> 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 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

Re: [bess] WG adoption and IPR poll for draft-salam-bess-evpn-oam-req-frmwk-01

[Yu Tianpeng]

Support this important work.
Thanks,
Tim

On Wed, 6 Feb 2019, 10:23 Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com wrote:

> This email begins a two-week poll for adoption of
> draft-salam-bess-evpn-oam-req-frmwk-01.txt
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> 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, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> 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.
>
>
>
> This poll for adoption closes on Wednesday 20th February 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
> ___
> 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] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[Yu Tianpeng]

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.

Regards,

Tim

 

发件人: Ali Sajassi (sajassi) [mailto:saja...@cisco.com] 
发送时间: 2019年1月12日 3:50
收件人: Yu Tianpeng; jorge.raba...@alcatel-lucent.com
抄送: stephane.litkow...@orange.com; bess@ietf.org
主题: Re: [bess] WGLC, IPR and implementation poll for
draft-ietf-bess-evpn-virtual-eth-segment

 

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 < <mailto:yutianpeng.i...@gmail.com>
yutianpeng.i...@gmail.com>
Date: Thursday, January 10, 2019 at 10:29 AM
To: Cisco Employee < <mailto:saja...@cisco.com> saja...@cisco.com>, "
<mailto:jorge.raba...@alcatel-lucent.com> jorge.raba...@alcatel-lucent.com"
< <mailto:jorge.raba...@alcatel-lucent.com>
jorge.raba...@alcatel-lucent.com>
Cc: " <mailto:stephane.litkow...@orange.com> stephane.litkow...@orange.com"
< <mailto:stephane.litkow...@orange.com> stephane.litkow...@orange.com>, "
<mailto:bess@ietf.org> bess@ietf.org" < <mailto:bess@ietf.org>
bess@ietf.org>
Subject: Re: [bess] WGLC, IPR and implementation poll for
draft-ietf-bess-evpn-virtual-eth-segment

 

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
Reasons:
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
processing??

 


3. Some wording changes are needed in 5.1
[Before]
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].
[After]
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 

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

[Yu Tianpeng]

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.

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
Thanks a lot.

Regards,
Tim


On Wed, 9 Jan 2019, 00:31 Mankamana Mishra (mankamis)  Thanks ali. I took look at the diff, it looks ok to me to move forward.
>
>
>
> Thanks
>
> Mankamana
>
>
>
>
>
> *From: *BESS  on behalf of "Ali Sajassi (sajassi)"
> 
> *Date: *Tuesday, January 8, 2019 at 3:17 PM
> *To: *Tim , "stephane.litkow...@orange.com" <
> stephane.litkow...@orange.com>, "bess@ietf.org" 
> *Subject: *Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-virtual-eth-segment
>
>
>
>
>
> Tim, Mankamana,
>
>
>
> The rev02 of the draft has the updates to address your latest comments.
>
>
>
> Cheers,
>
> Ali
>
>
>
> *From: *BESS  on behalf of Tim <
> yutianpeng.i...@gmail.com>
> *Date: *Monday, January 7, 2019 at 2:53 PM
> *To: *"stephane.litkow...@orange.com" , "
> bess@ietf.org" 
> *Subject: *Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-virtual-eth-segment
>
>
>
> Hi,
>
> 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.
>
> Thanks,
>
> Tim
>
>
>
> On 2018/12/3 18:43, stephane.litkow...@orange.com 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
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
>
> _
>
>
>
> 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
>
> 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] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[Yu Tianpeng]

Indeed, confused me when first read as hundreds and thousands are really
just example and no particular identification on real number an implement
should support.

On Fri, 7 Dec 2018, 16:57 Mankamana Mishra (mankamis)  Support.
>
>
>
>
>
> But I would be happy to see some changes if WG / Author agree to it.
>
>
>
> *Nits: *
>
>1. Please move abstract to the top. It would be easy for readers.
>2. It might be good to add a line to describe I-SID in terminology
>section
>
>
>
>
> 3.2
> .
> Scalability
>
>
>
>
>
>
>
>(R2a) A PE MUST handle thousands or tens of thousands of Single-homed
>
>vES's on a single physical port (e.g., single ENNI)
>
>
>
> *Comment*: These section provides number “thousands or ten thousands”. As
> a standard document, I think we can avoid using some hard code numbers.
>
> Would it be more appropriate to say “A PE MUST handle multiple
> Single-homed vES’s
>
> on a single physical port (e.g., single ENNI)
>
>
>
>
>
>(R2b) A PE MUST handle hundreds of Single-Active vES's on a single
>
>physical port (e.g., single ENNI)
>
> *Comment: Same as above *
>
>
>
>(R2c) A PE MAY handle tens or hundreds of All-Active Multi-Homed
>
>vES's on a single physical port (e.g., single ENNI)
>
> *Comment: Same as above *
>
>
>
>
>
>
>
> Thanks
>
> Mankamana
>
>
>
>
>
> *From: *BESS  on behalf of "
> stephane.litkow...@orange.com" 
> *Date: *Monday, December 3, 2018 at 2:43 AM
> *To: *"bess@ietf.org" 
> *Subject: *[bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-virtual-eth-segment
>
>
>
> 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
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
>
> _
>
>
>
> 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
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess