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

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 7 Jan 2019 03:22:53 +0000

Hi Stephane,

I just checked in a new revision of the document that incorporates the comments from Sasha and Mankamana. Rick also responded to the IPR call, so we are good to go.

Cheers,
Ali

From: BESS <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, December 17, 2018 at 4:55 AM
To: LITKOWSKI Stephane OBS/OINIS <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Hi,

The WGLC poll is now ended.
We have one comment from Mankamana that requires a reply from the authors.

We are also missing an IPR reply from Richard Schnell from Verizon.

We can’t proceed before clearing these two points.

Brgds,

Stephane

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 03, 2018 11:43
To: [email-masked]
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.

_________________________________________________________________________________________________________________________

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.

---

From: Tim <[email-masked]>
Date: Mon, 7 Jan 2019 22:52:46 +0800

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, [email-masked] wrote:
>
> Hello Working Group,
>
> This email starts a two-week Working Group Last Call on 
> draft-ietf-bess-evpn-virtual-eth-segment [1]
>
> 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.
>
> 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.
>
>     [1] 
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/
>
>     [2] 
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Mon, 7 Jan 2019 22:54:35 +0000

Thanks Ali for addressing my comments.

Sorry, some how I missed initially but not sure if these section have to be filled before it goes to next step, or it can move forward and  you can take care of this in next revision.

8<https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-eth-segment-01#section-8>. Security Considerations This document does not introduce anyadditional security constraints. <This has to go inside paragraph, right now it is part of heading. And you might want to say that it does not introduce any additional security consideration compare to RFC 7432 or any other RFC which you want to point out>

9<https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-eth-segment-01#section-9>. IANA Considerations

   TBD.  >>>>>> I think this document does add some new EC, do we need to write something here about it ?

Thanks
Mankamana

From: BESS <[email-masked]> on behalf of "Ali Sajassi (sajassi)" <[email-masked]>
Date: Sunday, January 6, 2019 at 7:23 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Hi Stephane,

Cheers,
Ali

Hi,

Brgds,

Stephane

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

Thank you.

---

From: Yu Tianpeng <[email-masked]>
Date: Mon, 7 Jan 2019 23:03:55 +0000

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) <[email-masked]
wrote:

> 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
> <https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-eth-segment-00#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 <[email-masked]> on behalf of "
> [email-masked]" <[email-masked]>
> *Date: *Monday, December 3, 2018 at 2:43 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-evpn-virtual-eth-segment
>
>
>
> Hello Working Group,
>
>
>
> 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.
>
>
>
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 8 Jan 2019 23:17:09 +0000

Tim, Mankamana,

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

Cheers,
Ali

From: BESS <[email-masked]> on behalf of Tim <[email-masked]>
Date: Monday, January 7, 2019 at 2:53 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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.

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?

Thanks,

Tim

On 2018/12/3 18:43, [email-masked]<mailto:[email-masked]> wrote:

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

BESS mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Wed, 9 Jan 2019 00:31:26 +0000

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

Thanks
Mankamana

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

Tim, Mankamana,

Cheers,
Ali

Hi,

2. There are 2 Figure 2

Thanks,

Tim

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

BESS mailing list

---

From: Yu Tianpeng <[email-masked]>
Date: Wed, 9 Jan 2019 12:03:14 +0000

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) <[email-masked]
wrote:

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 10 Jan 2019 06:17:49 +0000

From: Yu Tianpeng <[email-masked]>
Date: Wednesday, January 9, 2019 at 4:03 AM
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

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.

Cheers,
Ali

Thanks a lot.

Regards,
Tim

On Wed, 9 Jan 2019, 00:31 Mankamana Mishra (mankamis) <[email-masked]<mailto:[email-masked]> wrote:
Thanks ali. I took look at the diff, it looks ok to me to move forward.

Thanks
Mankamana

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 8, 2019 at 3:17 PM
To: Tim <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Tim, Mankamana,

Cheers,
Ali

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Tim <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 7, 2019 at 2:53 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Hi,

2. There are 2 Figure 2

Thanks,

Tim

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

BESS mailing list

---

From: Yu Tianpeng <[email-masked]>
Date: Thu, 10 Jan 2019 18:28:58 +0000

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.

2. 5.1 need changes from "CMAC" to "MAC". Probablly "Ethernet Segment" to
"vES" also will be better.
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..
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
version
Is my understanding correct?

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:)...
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
mode)

Thanks & Regards,
Tim

On Thu, 10 Jan 2019, 06:17 Ali Sajassi (sajassi) <[email-masked] wrote:

>
>
>
>
> *From: *Yu Tianpeng <[email-masked]>
> *Date: *Wednesday, January 9, 2019 at 4:03 AM
> *To: *Cisco Employee <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> 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.
>
>
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 11 Jan 2019 19:49:58 +0000

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 <[email-masked]>
Date: Thursday, January 10, 2019 at 10:29 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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.

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.

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 !!

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

“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 version
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.

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.

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 mode)

OK.

Cheers,

Ali

Thanks & Regards,
Tim

On Thu, 10 Jan 2019, 06:17 Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]> wrote:

From: Yu Tianpeng <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 9, 2019 at 4:03 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Cheers,
Ali

Thanks a lot.

Regards,
Tim

Thanks
Mankamana

Tim, Mankamana,

Cheers,
Ali

Hi,

2. There are 2 Figure 2

Thanks,

Tim

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

BESS mailing list

---

From: <[email-masked]>
Date: Tue, 15 Jan 2019 06:00:44 +0000

Hi Ali, Tim

I agree almost agree with Ali. There was a 2 week WGLC to gather comments which is now ended. However, as the WGLC conclusion was that an I-D update was required, I have let time for additional updates, but we cannot continue forever.

From the last set of email, I think that there is still a misunderstanding point on question 5 from Tim. As I think it is also very good to encourage participation/discussion/education, it will be worth agreeing on this one before closing an moving forward.

Tim,

Next time, it would be great that you raise your comments during the WGLC or even before (the sooner, the better).

Thanks,

Stephane

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Friday, January 11, 2019 20:50
To: Yu Tianpeng; [email-masked]
Cc: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Hi Stephane,

“per se” is and adverb.

4. Section 5.3

5. Still section 5.3

OK.

Cheers,

Ali

Thanks & Regards,
Tim

Cheers,
Ali

Thanks a lot.

Regards,
Tim

Thanks
Mankamana

Tim, Mankamana,

Cheers,
Ali

Hi,

2. There are 2 Figure 2

Thanks,

Tim

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

BESS mailing list

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 15 Jan 2019 18:45:21 +0000

Hi Stephane,

From: "[email-masked]" <[email-masked]>
Date: Monday, January 14, 2019 at 10:00 PM
To: Cisco Employee <[email-masked]>, Yu Tianpeng <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Hi Ali, Tim

Yes, the procedure described in section 5.3 is for EVCs in a physical ENNI but it also applies to logical ENNI and just like physical ENNI, a type-3 ESI is used for these logical ENNIs.

Cheers,
Ali

Tim,

Thanks,

Stephane

Hi Stephane,

“per se” is and adverb.

4. Section 5.3

5. Still section 5.3

OK.

Cheers,

Ali

Thanks & Regards,
Tim

Cheers,
Ali

Thanks a lot.

Regards,
Tim

Thanks
Mankamana

Tim, Mankamana,

Cheers,
Ali

Hi,

2. There are 2 Figure 2

Thanks,

Tim

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

BESS mailing list

Thank you.

---

From: <[email-masked]>
Date: Wed, 16 Jan 2019 13:54:36 +0000

Hi WG,

The document has been updated and we have gathered all the answers regarding the IPR poll.
The document will progress now to the next step.

Brgds,

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 17, 2018 13:55
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

Hi,

We can't proceed before clearing these two points.

Brgds,

Stephane

Hello Working Group,

    Thank you,

    Stephane & Matthew

Thank you.

Thank you.