Subject: Re: [Idr] [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Sat, 1 Aug 2020 08:29:44 +0000

I fully agree with Ali.
I think the VXLAN TLV only makes sense for other families, and not for EVPN. We’ve done EVPN public interoperability for a few years and everyone uses the BGP encap extends community.

Thanks,
Jorge

________________________________
From: BESS <[email-masked]> on behalf of Ali Sajassi (sajassi) <sajassi=[email-masked]>
Sent: Saturday, August 1, 2020 03:18
To: Susan Hares; [email-masked]; [email-masked]
Cc: Hu, Jun (Nokia - US/Mountain View)
Subject: Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

Sue,

I am afraid if we don’t clean up the draft, it can cause confusion as it has already and result in immediate errata filing for it after publication. A sub-bullet got added to the latest rev (rev17) that is not correct. It says that the VxLAN sub-tlv is sent with EVPN route when V bit not set. However, EVPN never uses this sub-tlv as its routes has all the needed info. Furthermore, RFC 8365 is very clear that EVPN uses Tunnel Encapsulation Extended Community (per section 4.1). As I said, I am not aware of any of the vendors using these sub-TVLs and it is easy to have a quick poll.

Regarding the paragraph that got omitted, it is making it much more ambiguous than it used to. I would opt for clarifying the paragraph rather than removing it. If needed I can provide an updated paragraph. Section 9 of RFC 8365 specifies how a VPN multicast route can be advertised with PMSI tunnel attribute and Encapsulation extended community and has been implemented by many vendors.

Cheers,
Ali

From: Susan Hares <[email-masked]>
Date: Friday, July 31, 2020 at 5:02 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" <[email-masked]>
Subject: RE: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali:

It is wise to start with the RFC6514 and the draft-ietf-idr-tunnel-encapsulation draft.

[WG chair hat on]
The tunnel-encapsulation draft has passed general WG LC – so it is inappropriate to call for the request to remove these sections.  The WG LC that is currently running is whether to remove the “AS” field from the tunnel endpoint field, and replace it with a reserved field.

The implementation page is on:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations

If you wish to provide information on the cisco implementation, you are welcome to add information on the page.
I can call for an update to the page from vendors.

[WG chair hat off[
[Document shepherd hat on]

The issue is during the edits the text from RFC6514 from Eric Rosen was unclear.  The text was:

   It has been suggested that it may sometimes be useful to attach a
   Tunnel Encapsulation attribute to a BGP UPDATE message that is also
   carrying a PMSI (Provider Multicast Service Interface) Tunnel
   attribute [RFC6514<https://datatracker.ietf.org/doc/html/rfc6514>].  If the PMSI Tunnel attribute specifies an IP
   tunnel, the Tunnel Encapsulation attribute could be used to provide
   additional information about the IP tunnel.  The usage of the Tunnel
   Encapsulation attribute in combination with the PMSI Tunnel attribute
   is outside the scope of this document.

Since the text itself was unclear what additional information could be provided, the authors removed it from the draft.

As we had not received any feedback about active RFC6514 interactions on the list.

[document shepherd off]

If you have an implementation of the interaction between the RF6514 and tunnel encapsulation, it would be valuable to provide:

a)  either a draft specifying the interaction you wish to IDR WG, or
b)  comments that could replace the original the original text.

Since the IDR draft has gone through multiple WG LC and a very complete review from Alvaro – so a quick response would be appreciated.   IMHO a draft on the interaction between RFC6514 and the tunnel-encapsulation draft – would be the best thing at this point.  Let me know if you are interested in working on such a draft.

Sue

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Friday, July 31, 2020 1:54 AM
To: Susan Hares; [email-masked]; [email-masked]
Cc: 'Hu, Jun (Nokia - US/Mountain View)'
Subject: Re: IPSec Tunnels and draft-sajassi-bess-secure-evpn

<added [email-masked]>

Sue,

Before getting to the discussions of the three IPsec proposals, there are some elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might have caused some confusions and I’d like to get those sorted out first.

The tunnel-encap draft specifies sub-tlv for VxLAN, VxLAN GDP, and NVGRE in sections 3.2.1, 3.2.2, and 3.2.3. I am not aware of any vendor that has implemented these sub-tlvs because the info in these sub-tlv already exist in EVPN routes (e.g., MAC addresses, Ethernet Tags, etc.) which they have implemented it. Therefore, all the vendors that I am aware of use Extended Community  defined in section 4.1  along with EVPN routes to signal VxLAN and GENEVE tunnel types. Furthermore, I am not aware of anyone using NVGRE encap! So, as the first step, we should remove these three sections from the draft if there is no objection.

Cheers,
Ali

From: Susan Hares <[email-masked]>
Date: Tuesday, July 28, 2020 at 8:30 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" <[email-masked]>
Subject: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali and bess WG:

IDR has 3 proposals for IPsec tunnels that impact draft-ietf-idr-tunnel-encaps-17.txt.  As an IDR co-chair/shepherd,  I have been discussing these three drafts (Ali and two other authors sets) to try to find out if we can have one general solutions.

The discussion has been very fruitful to point up BGP issues of interoperability, security, privacy, manageability, and scaling.  For example, there is a lack of a clear specification between RFC6514 (PMSI tunnel attribute) and the tunnel-encaps draft that specifies how these drafts interoperate.  I suspect the bess and idr chairs will need to discuss if tunnel-encaps has to address this point.

I wrote up my ideas in draft-hares-idr-bgp-ipsec-analysis-00.txt so the authors could tell me what I misunderstood.   You’ll find this draft stops half way.  I have the rest of the draft written, but I wanted feedback from all the author teams before sending it out.

After hearing some of the details from the authors, I would like to sponsor an IDR interim so we could discuss these issues at length.   If you think this is a good idea, please let me know.

One other thing… unfortunately, I scheduled a set of meetings for EDT time after IETF meetings this week.   Your next response will occur from 11-16 UTC on Wednesday.

Cheerily, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 1 Aug 2020 07:39:12 -0400

Rabadan: 

Thank you for your input.   Please review the details of the message I sent
to Ali. 

Synopsis: 

[IDR Chair hat]  We welcome implementation reports at: 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implement
ations

It's hard to ask authors to re-open old issues unless you have specific
implementation issues

substantiated on the wiki with an implementation report.   

You can put a comment at the bottom if you are unclear about the format. 

The person who puts the information must provide a name and an email
address.  

[IDR Chair hat off]

[Shepherd hat on] I will await the authors response to your queries on EVPN.
[Shepherd hat off] 

Thank you for bring up the EVPN related issues.  

Cheerily, Susan Hares 

From: BESS [mailto:[email-masked]] On Behalf Of Rabadan, Jorge (Nokia
- US/Mountain View)
Sent: Saturday, August 1, 2020 4:30 AM
To: Ali Sajassi (sajassi); Susan Hares; [email-masked]; [email-masked]
Cc: Hu, Jun (Nokia - US/Mountain View)
Subject: Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

I fully agree with Ali.

I think the VXLAN TLV only makes sense for other families, and not for EVPN.
We've done EVPN public interoperability for a few years and everyone uses
the BGP encap extends community.

Thanks,

Jorge 

  _____  

From: BESS <[email-masked]> on behalf of Ali Sajassi (sajassi)
<sajassi=[email-masked]>
Sent: Saturday, August 1, 2020 03:18
To: Susan Hares; [email-masked]; [email-masked]
Cc: Hu, Jun (Nokia - US/Mountain View)
Subject: Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn 

Sue,

I am afraid if we don't clean up the draft, it can cause confusion as it has
already and result in immediate errata filing for it after publication. A
sub-bullet got added to the latest rev (rev17) that is not correct. It says
that the VxLAN sub-tlv is sent with EVPN route when V bit not set. However,
EVPN never uses this sub-tlv as its routes has all the needed info.
Furthermore, RFC 8365 is very clear that EVPN uses Tunnel Encapsulation
Extended Community (per section 4.1). As I said, I am not aware of any of
the vendors using these sub-TVLs and it is easy to have a quick poll.

Regarding the paragraph that got omitted, it is making it much more
ambiguous than it used to. I would opt for clarifying the paragraph rather
than removing it. If needed I can provide an updated paragraph. Section 9 of
RFC 8365 specifies how a VPN multicast route can be advertised with PMSI
tunnel attribute and Encapsulation extended community and has been
implemented by many vendors.

Cheers,

Ali

From: Susan Hares <[email-masked]>
Date: Friday, July 31, 2020 at 5:02 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" <[email-masked]>
Subject: RE: IPSec Tunnels and draft-sajassi-bess-secure-evpn 

Ali:

It is wise to start with the RFC6514 and the
draft-ietf-idr-tunnel-encapsulation draft..   

[WG chair hat on] 

The tunnel-encapsulation draft has passed general WG LC - so it is
inappropriate to call for the request to remove these sections.  The WG LC
that is currently running is whether to remove the "AS" field from the
tunnel endpoint field, and replace it with a reserved field.. 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implement
ations

If you wish to provide information on the cisco implementation, you are
welcome to add information on the page. 

[WG chair hat off[

The issue is during the edits the text from RFC6514 from Eric Rosen was
unclear.  The text was: 

   attribute [ <https://datatracker.ietf.org/doc/html/rfc6514> RFC6514].  If
the PMSI Tunnel attribute specifies an IP

Since the text itself was unclear what additional information could be
provided, the authors removed it from the draft. 

As we had not received any feedback about active RFC6514 interactions on the
list. 

[document shepherd off]

If you have an implementation of the interaction between the RF6514 and
tunnel encapsulation, it would be valuable to provide:

Since the IDR draft has gone through multiple WG LC and a very complete
review from Alvaro - so a quick response would be appreciated.   IMHO a
draft on the interaction between RFC6514 and the tunnel-encapsulation draft
- would be the best thing at this point.  Let me know if you are interested
in working on such a draft. 

Sue 

<added [email-masked]>

Sue,

Before getting to the discussions of the three IPsec proposals, there are
some elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might
have caused some confusions and I'd like to get those sorted out first. 

The tunnel-encap draft specifies sub-tlv for VxLAN, VxLAN GDP, and NVGRE in
sections 3.2.1, 3.2.2, and 3.2.3. I am not aware of any vendor that has
implemented these sub-tlvs because the info in these sub-tlv already exist
in EVPN routes (e.g., MAC addresses, Ethernet Tags, etc.) which they have
implemented it. Therefore, all the vendors that I am aware of use Extended
Community  defined in section 4.1  along with EVPN routes to signal VxLAN
and GENEVE tunnel types. Furthermore, I am not aware of anyone using NVGRE
encap! So, as the first step, we should remove these three sections from the
draft if there is no objection. 

Cheers,

Ali

Ali and bess WG: 

IDR has 3 proposals for IPsec tunnels that impact
draft-ietf-idr-tunnel-encaps-17.txt.  As an IDR co-chair/shepherd,  I have
been discussing these three drafts (Ali and two other authors sets) to try
to find out if we can have one general solutions.   

The discussion has been very fruitful to point up BGP issues of
interoperability, security, privacy, manageability, and scaling..  For
example, there is a lack of a clear specification between RFC6514 (PMSI
tunnel attribute) and the tunnel-encaps draft that specifies how these
drafts interoperate.  I suspect the bess and idr chairs will need to discuss
if tunnel-encaps has to address this point. 

I wrote up my ideas in draft-hares-idr-bgp-ipsec-analysis-00.txt so the
authors could tell me what I misunderstood.   You'll find this draft stops
half way.  I have the rest of the draft written, but I wanted feedback from
all the author teams before sending it out. 

After hearing some of the details from the authors, I would like to sponsor
an IDR interim so we could discuss these issues at length.   If you think
this is a good idea, please let me know. 

One other thing. unfortunately, I scheduled a set of meetings for EDT time
after IETF meetings this week.   Your next response will occur from 11-16
UTC on Wednesday. 

Cheerily, Sue

---

From: John E Drake <[email-masked]>
Date: Sun, 2 Aug 2020 15:36:57 +0000

Hi,

I also agree with Ali.  Eric specifically included the Tunnel Encapsulation Extended Community in his draft at our request in order to support RFC 8365.  I.e., the draft that became RFC 8365 initially used the Tunnel Encapsulation Extended Community defined in RFC 5512 and pre-dated by several years the initial version of Eric's draft, which did not have the Tunnel Encapsulation Extended Community.

Yours Irrespectively,

John

Juniper Business Use Only
From: BESS <[email-masked]> On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View)
Sent: Saturday, August 1, 2020 4:30 AM
To: Ali Sajassi (sajassi) <sajassi=[email-masked]>; Susan Hares <[email-masked]>; [email-masked]; [email-masked]
Cc: Hu, Jun (Nokia - US/Mountain View) <[email-masked]>
Subject: Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

[External Email. Be cautious of content]

I fully agree with Ali.
I think the VXLAN TLV only makes sense for other families, and not for EVPN. We've done EVPN public interoperability for a few years and everyone uses the BGP encap extends community.

Thanks,
Jorge

________________________________
From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Ali Sajassi (sajassi) <sajassi=[email-masked]<mailto:sajassi=[email-masked]>>
Sent: Saturday, August 1, 2020 03:18
To: Susan Hares; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Hu, Jun (Nokia - US/Mountain View)
Subject: Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

Sue,

I am afraid if we don't clean up the draft, it can cause confusion as it has already and result in immediate errata filing for it after publication. A sub-bullet got added to the latest rev (rev17) that is not correct. It says that the VxLAN sub-tlv is sent with EVPN route when V bit not set. However, EVPN never uses this sub-tlv as its routes has all the needed info. Furthermore, RFC 8365 is very clear that EVPN uses Tunnel Encapsulation Extended Community (per section 4.1). As I said, I am not aware of any of the vendors using these sub-TVLs and it is easy to have a quick poll.

Cheers,
Ali

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 31, 2020 at 5:02 AM
To: Cisco Employee <[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]>>
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" <[email-masked]<mailto:[email-masked]>>
Subject: RE: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali:

It is wise to start with the RFC6514 and the draft-ietf-idr-tunnel-encapsulation draft..

[WG chair hat on]
The tunnel-encapsulation draft has passed general WG LC - so it is inappropriate to call for the request to remove these sections.  The WG LC that is currently running is whether to remove the "AS" field from the tunnel endpoint field, and replace it with a reserved field..

The implementation page is on:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations<https://urldefense.com/v3/__https:/trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps*20implementations__;JQ!!NEt6yMaO-gk!W5VnNHyc3oP29X0LQ_irbSTb8nBnntL-309BArYBPAtGu2up9mlhbj7kYmr1rr8$>

[WG chair hat off[

   attribute [RFC6514<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6514__;!!NEt6yMaO-gk!W5VnNHyc3oP29X0LQ_irbSTb8nBnntL-309BArYBPAtGu2up9mlhbj7kV1TIiiU$>].  If the PMSI Tunnel attribute specifies an IP

[document shepherd off]

Since the IDR draft has gone through multiple WG LC and a very complete review from Alvaro - so a quick response would be appreciated.   IMHO a draft on the interaction between RFC6514 and the tunnel-encapsulation draft - would be the best thing at this point.  Let me know if you are interested in working on such a draft.

Sue

To: Susan Hares; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

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

Sue,

Before getting to the discussions of the three IPsec proposals, there are some elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might have caused some confusions and I'd like to get those sorted out first.

Cheers,
Ali

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 28, 2020 at 8:30 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" <[email-masked]<mailto:[email-masked]>>
Subject: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali and bess WG:

The discussion has been very fruitful to point up BGP issues of interoperability, security, privacy, manageability, and scaling..  For example, there is a lack of a clear specification between RFC6514 (PMSI tunnel attribute) and the tunnel-encaps draft that specifies how these drafts interoperate.  I suspect the bess and idr chairs will need to discuss if tunnel-encaps has to address this point.

I wrote up my ideas in draft-hares-idr-bgp-ipsec-analysis-00.txt so the authors could tell me what I misunderstood.   You'll find this draft stops half way.  I have the rest of the draft written, but I wanted feedback from all the author teams before sending it out.

One other thing... unfortunately, I scheduled a set of meetings for EDT time after IETF meetings this week.   Your next response will occur from 11-16 UTC on Wednesday.

Cheerily, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 2 Aug 2020 21:41:53 -0400

John: 

Thank you for your history lesson.    Implementation specifics helpful on
the IDR wiki page regarding tunnel-encapsulation draft. 

I suggest you chat with John Scudder (one of the co-authors on the draft)
regarding your concerns.  

Sue 

From: John E Drake [mailto:[email-masked]] 
Sent: Sunday, August 2, 2020 11:37 AM
To: Rabadan, Jorge (Nokia - US/Mountain View); Ali Sajassi (sajassi); Susan
Hares; [email-masked]; [email-masked]
Cc: Hu, Jun (Nokia - US/Mountain View)
Subject: RE: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

Hi,

I also agree with Ali.  Eric specifically included the Tunnel Encapsulation
Extended Community in his draft at our request in order to support RFC 8365.
I.e., the draft that became RFC 8365 initially used the Tunnel Encapsulation
Extended Community defined in RFC 5512 and pre-dated by several years the
initial version of Eric's draft, which did not have the Tunnel Encapsulation
Extended Community.

Yours Irrespectively,

John

From: BESS <[email-masked]> On Behalf Of Rabadan, Jorge (Nokia -
US/Mountain View)
Sent: Saturday, August 1, 2020 4:30 AM
To: Ali Sajassi (sajassi) <sajassi=[email-masked]>; Susan Hares
<[email-masked]>; [email-masked]; [email-masked]
Cc: Hu, Jun (Nokia - US/Mountain View) <[email-masked]>
Subject: Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

I fully agree with Ali.

Thanks,

Jorge 

  _____  

Sue,

Cheers,

Ali

Ali:

[WG chair hat on] 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implement
ations
<https://urldefense.com/v3/__https:/trac.ietf.org/trac/idr/wiki/draft-ietf-i
dr-tunnel-encaps*20implementations__;JQ!!NEt6yMaO-gk!W5VnNHyc3oP29X0LQ_irbST
b8nBnntL-309BArYBPAtGu2up9mlhbj7kYmr1rr8$> 

[WG chair hat off[

   attribute [
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6514__;
!!NEt6yMaO-gk!W5VnNHyc3oP29X0LQ_irbSTb8nBnntL-309BArYBPAtGu2up9mlhbj7kV1TIii
U$> RFC6514].  If the PMSI Tunnel attribute specifies an IP

[document shepherd off]

Sue 

<added [email-masked]>

Sue,

Cheers,

Ali

Ali and bess WG: 

Cheerily, Sue

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 3 Aug 2020 07:00:10 +0000

Sue and authors,

To be clear, and John/Ali can chime in too, what I think we are saying is:

  *   people use RFC8365 as the reference to implement EVPN for VXLAN, VXLAN GPE, NVGRE and MPLS-in-GRE.
  *   RFC8365 uses the encapsulation extended community described in section 4.1 of the tunnel-encaps draft, and not the sub-TLVs in section 3.2.
  *   Because of that, new implementers of EVPN could be confused whether to use the encap extended community or the sub-TLVs. And the use of the latter would lead to interop issues.

Because of that, I am not suggesting to remove the TLVs in section 3.2, *but* I am asking to add a sentence in section 3.2 saying something like “The Encapsulation Sub-TLVs specified in sections 3.2.1, 3.2.2, 3.2.3 and 3.2.6 MUST NOT be used along with BGP UPDATE messages of AFI/SAFI 25/70 (EVPN).”

NOTE: the sub-TLVs are not useful for EVPN but can still be used with other families, i.e. 1/128 or 2/128, hence they should be kept in the document.

Now, Sue, authors, would that be possible?
@Sue, I’m happy to provide information about our EVPN implementation in the wiki, but it is about RFC8365 and not the tunnel-encaps draft. We can also point at this public interop report [1], where all the vendors listed in the EVPN tests for VXLAN encapsulation use the BGP encapsulation extended community and NOT the sub-TLVs used in section 3.2 of the tunnel-encaps draft.

[1] http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf

Thanks.
Jorge

From: Susan Hares <[email-masked]>
Date: Saturday, August 1, 2020 at 1:39 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>, 'Ali Sajassi (sajassi)' <sajassi=[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Cc: Hu, Jun (Nokia - US/Mountain View) <[email-masked]>
Subject: RE: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn
Rabadan:

Thank you for your input.   Please review the details of the message I sent to Ali.

Synopsis:

It’s hard to ask authors to re-open old issues unless you have specific implementation issues
substantiated on the wiki with an implementation report.
You can put a comment at the bottom if you are unclear about the format.
The person who puts the information must provide a name and an email address.
[IDR Chair hat off]
[Shepherd hat on] I will await the authors response to your queries on EVPN.  [Shepherd hat off]

Cheerily, Susan Hares

From: BESS [mailto:[email-masked]] On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View)

I fully agree with Ali.

Thanks,
Jorge

Sue,

Cheers,
Ali

Ali:

[WG chair hat on]
The tunnel-encapsulation draft has passed general WG LC – so it is inappropriate to call for the request to remove these sections.  The WG LC that is currently running is whether to remove the “AS” field from the tunnel endpoint field, and replace it with a reserved field..

[WG chair hat off[

[document shepherd off]

Sue

<added [email-masked]>

Sue,

Cheers,
Ali

Ali and bess WG:

Cheerily, Sue