Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-10 Thread Ali Sajassi (sajassi) 

Hi Thomas,

I have incorporated your comments into rev11 of the document. 

Cheers,
Ali

On 12/8/17, 1:45 AM, "Thomas Morin"  wrote:

Ali,

A few nits, sorry for not answering earlier:
>   
> I added the following paragraph to section 6 for clarification:
> “When a PE advertises multiple supported encapsulations, it MUST
> advertise encapsulations that use the same EVPN procedures including
> procedures associated with split-horizon filtering described in
> section 8.3.1. For example, VxLAN and NvGRE (or MPLS and MPLS over
> GRE) encapsulations use the same EVPN procedures and thus a PE can
> advertise both of them and can support either of them or both of them
> simultaneously. However, a PE MUST NOT advertise VxLAN and MPLS 

You should say "VxLAN/NVGRE" here to be consistent with the rest of the
document that treats VXLAN and NVGRE equally.

> encapsulations together because a) MPLS field of EVPN routes is set 

- s/MPLS field/the MPLS field/
- "(a)" instead of "a)" would be a bit more readable

> to either a MPLS label for a VNI but not both and b) some of EVPN 

- s/a MPLS label/an MPLS label/
- s/for a VNI/or a VNI/
- s/some of EVPN/some EVPN/  (?)

> procedures (such as split-horizon filtering) are different for
> VxLAN/NvGRE and MPLS encapsulations.”

Thanks,

-Thomas


 



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-08 Thread Thomas Morin 
Ali,

A few nits, sorry for not answering earlier:
>   
> I added the following paragraph to section 6 for clarification:
> “When a PE advertises multiple supported encapsulations, it MUST
> advertise encapsulations that use the same EVPN procedures including
> procedures associated with split-horizon filtering described in
> section 8.3.1. For example, VxLAN and NvGRE (or MPLS and MPLS over
> GRE) encapsulations use the same EVPN procedures and thus a PE can
> advertise both of them and can support either of them or both of them
> simultaneously. However, a PE MUST NOT advertise VxLAN and MPLS 

You should say "VxLAN/NVGRE" here to be consistent with the rest of the
document that treats VXLAN and NVGRE equally.

> encapsulations together because a) MPLS field of EVPN routes is set 

- s/MPLS field/the MPLS field/
- "(a)" instead of "a)" would be a bit more readable

> to either a MPLS label for a VNI but not both and b) some of EVPN 

- s/a MPLS label/an MPLS label/
- s/for a VNI/or a VNI/
- s/some of EVPN/some EVPN/  (?)

> procedures (such as split-horizon filtering) are different for
> VxLAN/NvGRE and MPLS encapsulations.”

Thanks,

-Thomas


 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-08 Thread Thomas Morin 
Ali Sajassi (sajassi), 2017-12-08 03:01:
> M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-
> > GPE, RFC4023
> >  
> > [Ali] Please refer to Thomas explanation on this which is copied
> > here for your convenience:
> > “My process fu is weakening, but if this specification is standard
> > track
> > (and I believe it should be), I believe it can't normatively depend
> > on
> > Informative specs and some of the above are in this category.”
> 
> My reply:
> It can if we call the Down References out in the IETF Last Call and
> no one opposes.  I think we already processed at least one document
> with a DownRef toVXLAN, so I don’t think that’s a problem.
> In any case, the type of Reference should be decided based on the
> real dependency of the document, not on its status.
> [Ali2] Done. 

I've just updated the shepherd review to list the downward references.

Best,

-Thomas

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-07 Thread Ali Sajassi (sajassi) 
Hi Alvaro,

I took care of your remaining comments and published rev10 of the document just 
now. For more details please see my replies inline.

Cheers,
Ali

From: Alvaro Retana <aretana.i...@gmail.com>
Date: Thursday, December 7, 2017 at 6:07 AM
To: "bess-cha...@ietf.org" <bess-cha...@ietf.org>, Cisco Employee 
<saja...@cisco.com>
Cc: Thomas Morin <thomas.mo...@orange.com>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

On December 5, 2017 at 10:53:02 PM, Ali Sajassi (sajassi) 
(saja...@cisco.com<mailto:saja...@cisco.com>) wrote:

Ali:

Hi!
Thanks for the review. Please refer to my replies to your comments marked with 
[Ali] inline. I have incorporated them in rev09 of the draft that has just been 
published. Please let me know if you have any other comments.

The only significant issues left are about the references (see below).

I need the Normative references to be in place so I can start the IETF LC (and 
can point them out there).  As soon as you post an update I’ll start the LC.

[Ali2] Done.

Thanks!

Alvaro.



...

M3. From 5.2 (MPLS over GRE):

M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD be 
present, and SHOULD be used to provide a 32-bit entropy field.”  What are the 
cases when it is ok not to include the field, or use it for that purpose?  IOW, 
why are these SHOULDs not MUSTs?  Or maybe, when is the key field needed?

[Ali] The reason it is a “SHOULD” because, the MPLS over GRE encap still works 
without the key field set to the entropy value; however, if that’s done, then 
ECMP won’t work well in the network. Also, the core routers in the network may 
not support ECMP based on GRE key and that’s another reason for “SHOULD”.

Can you include something along those lines?

[Ali2] Yes, I modified it to the following:

“…it is recommended that the GRE key field be present and be used to provide a 
32-bit entropy value only if the P nodes can perform ECMP hashing based on the 
GRE key; otherwise, the GRE header should not include the GRE key.”



...
M8. References

M8.1. TUNNEL-ENCAP (aka draft-ietf-idr-tunnel-encaps) should be Normative, 
which btw is marked to Obsolete rfc5512; I mention this because both are listed 
in several parts, so you should take rfc5512 out.

[Ali] Please refer to Thomas explanation on this which is copied here for your 
convenience:
“This was debated on a while ago, and this is somehow the conclusion of
the discussion:

https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w

Copy-paste:

We'll also add idr-tunnel-encaps a Informative reference. With respect
to Tunnel Encap Extended Community (which is the only part of
idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft
itself references RFC 5512.

During the course of WG LC and RFC editorship of evpn-overlay draft, if
we see that idr-tunnel-encap is progressing fast, then we can drop the
reference to RFC 5512 and make the reference to idr-tunnel-encap
Normative. Otherwise, we'll keep both references with RFC 5512 as
Normative and idr-tunnel-encap as Informative.


The question probably is whether or not idr-tunnel-encap progress is
sufficient.”

As I replied back:

If anything, both references should at least be of the same type: I can see no 
reasoning why one would be Normative and the other Informative.

In this case, idr-tunnel-encap already went through WGLC (according to the 
datatracker) — we can’t ignore the fact that idr has consensus on deprecating 
rfc5512.  Again, we don’t need both references.

[Ali2] Got rid off rfc5512 and moved the idr-tunnel-encap to normative.


M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE, RFC4023

[Ali] Please refer to Thomas explanation on this which is copied here for your 
convenience:
“My process fu is weakening, but if this specification is standard track
(and I believe it should be), I believe it can't normatively depend on
Informative specs and some of the above are in this category.”

My reply:

It can if we call the Down References out in the IETF Last Call and no one 
opposes.  I think we already processed at least one document with a DownRef 
toVXLAN, so I don’t think that’s a problem.

In any case, the type of Reference should be decided based on the real 
dependency of the document, not on its status.

[Ali2] Done.




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-07 Thread Alvaro Retana 
On December 5, 2017 at 10:53:02 PM, Ali Sajassi (sajassi) (saja...@cisco.com)
wrote:

Ali:

Hi!

Thanks for the review. Please refer to my replies to your comments marked
with [Ali] inline. I have incorporated them in rev09 of the draft that has
just been published. Please let me know if you have any other comments.

The only significant issues left are about the references (see below).

I need the Normative references to be in place so I can start the IETF LC
(and can point them out there).  As soon as you post an update I’ll start
the LC.

Thanks!

Alvaro.



...

M3. From 5.2 (MPLS over GRE):



M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD
be present, and SHOULD be used to provide a 32-bit entropy field.”  What
are the cases when it is ok not to include the field, or use it for that
purpose?  IOW, why are these SHOULDs not MUSTs?  Or maybe, when is the key
field needed?



[Ali] The reason it is a “SHOULD” because, the MPLS over GRE encap still
works without the key field set to the entropy value; however, if that’s
done, then ECMP won’t work well in the network. Also, the core routers in
the network may not support ECMP based on GRE key and that’s another reason
for “SHOULD”.

Can you include something along those lines?


...

M8. References



M8.1. TUNNEL-ENCAP (aka draft-ietf-idr-tunnel-encaps) should be Normative,
which btw is marked to Obsolete rfc5512; I mention this because both are
listed in several parts, so you should take rfc5512 out.



[Ali] Please refer to Thomas explanation on this which is copied here for
your convenience:

“This was debated on a while ago, and this is somehow the conclusion of

the discussion:



https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w



Copy-paste:



We'll also add idr-tunnel-encaps a Informative reference. With respect

to Tunnel Encap Extended Community (which is the only part of

idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft

itself references RFC 5512.



During the course of WG LC and RFC editorship of evpn-overlay draft, if

we see that idr-tunnel-encap is progressing fast, then we can drop the

reference to RFC 5512 and make the reference to idr-tunnel-encap

Normative. Otherwise, we'll keep both references with RFC 5512 as

Normative and idr-tunnel-encap as Informative.





The question probably is whether or not idr-tunnel-encap progress is

sufficient.”

As I replied back:

If anything, both references should at least be of the same type: I can see
no reasoning why one would be Normative and the other Informative.

In this case, idr-tunnel-encap already went through WGLC (according to the
datatracker) — we can’t ignore the fact that idr has consensus on
deprecating rfc5512.  Again, we don’t need both references.


M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE, RFC4023



[Ali] Please refer to Thomas explanation on this which is copied here for
your convenience:

“My process fu is weakening, but if this specification is standard track

(and I believe it should be), I believe it can't normatively depend on

Informative specs and some of the above are in this category.”

My reply:

It can if we call the Down References out in the IETF Last Call and no one
opposes.  I think we already processed at least one document with a DownRef
toVXLAN, so I don’t think that’s a problem.

In any case, the type of Reference should be decided based on the real
dependency of the document, not on its status.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-06 Thread Ali Sajassi (sajassi) 


I will add the following sentence to the abstract.
“This specification is also applicable to other NVO encapsulations such as 
GENEVE, GPE, and GUE; however, these encapsulations may require additional 
incremental work and thus will be specified in separate document(s).”

I think that mentioning other encapsulations (beyond Geneve) is not necessary 
(and may raise more questions).  IOW, I like Martin’s suggested text more.

OK, I changed the sentence to the following:

“This specification is also applicable to [GENEVE] encapsulation; however, some 
incremental work is required which will be covered in a separate document 
[EVPN-GENEVE].”

In either case, at least add an Informative reference to 
draft-boutros-bess-evpn-geneve.

Done.

Cheers,

Ali

Thanks!

Alvaro.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-06 Thread Alvaro Retana 
On December 6, 2017 at 6:52:42 AM, Ali Sajassi (sajassi) (saja...@cisco.com)
wrote:


Martin Vigoureux, 2017-12-05 11:34:

Perhaps draft-ietf-bess-evpn-overlay could hint on such a Geneve
work for EVPN; something like: "Adapting the EVPN control plane to the
Geneve encapsulation is out of the scope of this document, and is
expected to be covered in a separate document based on the same
architectural principles"

I will add the following sentence to the abstract.
“This specification is also applicable to other NVO encapsulations such as
GENEVE, GPE, and GUE; however, these encapsulations may require additional
incremental work and thus will be specified in separate document(s).”

I think that mentioning other encapsulations (beyond Geneve) is not
necessary (and may raise more questions).  IOW, I like Martin’s suggested
text more.

In either case, at least add an Informative reference
to draft-boutros-bess-evpn-geneve.

Thanks!

Alvaro.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-06 Thread Alvaro Retana 
On December 4, 2017 at 5:16:49 PM, John E Drake (jdr...@juniper.net) wrote:

(1) Coordination with nv03



For the Chairs:  Except for some clarification comments [1] related to the
current version, I see no other traffic in the nvo3 list related to this
document.  Was there some other coordination that I’m missing?   I am not
questioning having this document in bess (that’s perfectly fine); I’m just
raising the needed coordination with other WGs, from the Charter: "The
working group will also coordinate with...NVO3 working group
for coordination of protocols to support data center VPNs.”



*[JD]  This draft had been around for nearly five years and the
coordination happened a long time ago.  Because NVO3 was not chartered to
work on a control plane, the coordination was mainly to ensure that this
draft met the requirements specified by that group.*




The coordination I’m talking about is not the one related to the decision
of where the work should be done.  The question is to raise the point that
if bess (in the case) is doing work related nvo3, then ideally the document
wold have been flagged to nvo3 when it went into WGLC to allow them to
review and comment.

In this case, I don’t think this document includes anything that would be
contentious in nvo3 — so I’m happy to explicitly let the WG know when we
start the IETF LC.

Alvaro.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-06 Thread Ali Sajassi (sajassi) 
Hi Thomas,

Please see my reply inline.

On 12/5/17, 6:25 AM, "BESS on behalf of thomas.mo...@orange.com" 
 wrote:

All,

Martin Vigoureux, 2017-12-05 11:34:

Perhaps draft-ietf-bess-evpn-overlay could hint on such a Geneve
work for EVPN; something like: "Adapting the EVPN control plane to the
Geneve encapsulation is out of the scope of this document, and is
expected to be covered in a separate document based on the same
architectural principles" 

I will add the following sentence to the abstract.
“This specification is also applicable to other NVO encapsulations such as 
GENEVE, GPE, and GUE; however, these encapsulations may require additional 
incremental work and thus will be specified in  separate document(s).”


(Related to this sentence, but not related to your question:)

I recently realized that I'm unclear on this point: the way the MPLS
label fields are decoded is not the same for a VXLAN or NVGRE encap
(where the whole 3 bytes are used) than for an MPLS encap (where only
the topmost 20 bits of the 3 bytes are used). This means that, although
the encoding is unambiguous when one encap is used (or when VXLAN and
NVGRE would be used at the same time), it becomes ambiguous when a mix
is used, for instance MPLS and VXLAN, unless the dataplane MPLS label
to use is equal to the VNI after a 4-bit left shifting.

If I'm not wrong "...routes MAY be advertised with multiple
  encapsulation types" needs to be restricted to the cases that work.
  
  
I added the following paragraph to section 6 for clarification:
“When a PE advertises multiple supported encapsulations, it MUST advertise 
encapsulations that use the same EVPN procedures including procedures 
associated with split-horizon filtering described in section 8.3.1. For 
example, VxLAN and NvGRE (or MPLS and MPLS over GRE) encapsulations use the 
same EVPN procedures and thus a PE can advertise both of them and can support 
either of them or both of them simultaneously. However, a PE MUST NOT advertise 
VxLAN and MPLS encapsulations together because a) MPLS field of EVPN routes is 
set to either a MPLS label for a VNI but not both and b) some of EVPN 
procedures (such as split-horizon filtering) are different for VxLAN/NvGRE and 
MPLS encapsulations.”

Cheers,
Ali
 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread Ali Sajassi (sajassi) 
Hi Alvaro,

Thanks for the review. Please refer to my replies to your comments marked with 
[Ali] inline. I have incorporated them in rev09 of the draft that has just been 
published. Please let me know if you have any other comments.

Regards,
Ali

From: BESS <bess-boun...@ietf.org> on behalf of Alvaro Retana 
<aretana.i...@gmail.com>
Date: Monday, December 4, 2017 at 1:49 PM
To: "bess-cha...@ietf.org" <bess-cha...@ietf.org>
Cc: Thomas Morin <thomas.mo...@orange.com>, "bess@ietf.org" <bess@ietf.org>
Subject: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

Dear Authors:

I just finished reading this document (finally!).  I have a some comments (see 
below) which I think should be easy to address.

I also have some bigger issues that we’ll need the Chairs’ help to solve:

(1) Coordination with nv03

For the Chairs:  Except for some clarification comments [1] related to the 
current version, I see no other traffic in the nvo3 list related to this 
document.  Was there some other coordination that I’m missing?   I am not 
questioning having this document in bess (that’s perfectly fine); I’m just 
raising the needed coordination with other WGs, from the Charter: "The working 
group will also coordinate with...NVO3 working group for coordination of 
protocols to support data center VPNs.”

[Ali] The chairs have already addressed the coordination with NOV3. I just want 
to add that the initial versions of this draft were presented in NOV3 WG long 
time ago; however, because this draft is about the control plane, the 
discussions have been happening in the BESS WG. Also as Martin mentioned, there 
have been some tutorial preso and a applicability draft written for NOV3 
consumption and presented over past couple of IETF meetings at NOV3 WG.

What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is focusing on Geneve 
as the Standard encapsulation, but this document doesn’t even mention it.

[Ali] Geneve has become a standard just recently and a few months ago Thomas 
mentioned to us that we should have coverage for it and we turned around 
quickly and published a draft for it to show how this draft with little 
extension can be used for Geneve encapsulation.


(2) Document Status

Why is this a Standards Track document?  The Abstract/Introduction say that 
“this document describes how Ethernet VPN (EVPN) can be used as an NVO solution 
and explores applicability of EVPN functions and procedures.”  -- if it’s just 
a description (as the text clearly is), and not a technical specification, then 
why it is not Informational?

[Ali] As suggested by Thomas and Martin, I will change the wording to say 
“specifies” instead of “describes”. This document is definitely a Standard 
Track document because it specifies procedures, EVPN route formats, and 
operations for different service types for NV overlay.

I can see how we could call it an Applicability Statement (rfc2026) and still 
publish it in the Standards Track.  If we want to go that way, we would need 
some minor updates to make it clear that this is an Applicability Statement and 
is not intended to stand in for a Technical Specification.  I am not clear on 
the process as it related to possible DownRefs (see below), but I’m willing to 
Last Call an Applicability Statement in the Standards Track…if that is what you 
want.

[Ali] I have updated the draft by adding the following sentence to the abstract 
to clarify the point that this document is a Technical Specification:

“This document also specifies new multi-homing procedures for split-horizon 
filtering and mass-withdraw. It also specifies EVPN route constructions for 
VxLAN / NvGRE encapsulations and ASBR procedures for multi-homing NV Edge 
devices.”



Thanks!

Alvaro.


[1] 
https://mailarchive.ietf.org/arch/msg/nvo3/cd0hOfb966ROcL4t8JCrBD28bBg/?qid=c9f632dc5d6aab5e4b22972bb242baf0



Major:

M1. Section 5.1.2.1 (Auto Derivation of RT) shows a “packet format” to 
illustrate how the RT can be auto-derived.  Without any context, the 
description doesn’t make much sense: the fields are not described in order, the 
reader is expected to know about global and local administrative fields, the 
“A-bit” (or the Type field) are not mentioned in the description, people could 
probably guess that “D-ID” means “domain-id”, there’s no indication of what to 
do with that “packet format”, etc.  Please clean the description up, include 
clearer explanations and some references can’t hurt.

[Ali] Done.

M1.2. What about 4-byte ASNs?

[Ali] In such case, RT cannot be auto-derived. I have added the following 
paragraph to the end of 5.1.2:
“It should be noted that RT auto-derivation is applicable for 2-octet AS 
numbers. For 4-octet AS numbers, RT needs to be manually configured since 
3-octet VNI fields cannot be fit within 2-octet local administrator field.”

M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be advertised 
with multiple encap

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread Martin Vigoureux 

Alvaro,

the docs are
draft-boutros-bess-evpn-geneve-00
draft-rabadan-nvo3-evpn-applicability-00

-m

Le 05/12/2017 à 23:08, Alvaro Retana a écrit :

On December 5, 2017 at 9:25:39 AM, thomas.mo...@orange.com
 (thomas.mo...@orange.com
) wrote:


All,

Martin Vigoureux, 2017-12-05 11:34:


Alvaro: [...]


What about Geneve (draft-ietf-nvo3-geneve)? The nvo3 WG is
focusing on
Geneve as the Standard encapsulation, but this document doesn’t
even mention it.


Indeed. But The decision by NVO3 to work on Geneve is fairly recent.
I have indicated in the BESS report that we'll likely be working
closeer
with NVO3 from now on. An individual draft on the applicability of
EVPN
to NVO3 networks is targeting NVO3 WG. Conversely, an individual
draft
on EVPN extensions for Geneve is targeting BESS. We have agreed that
we'll do cross reviews at the important milestones of these docs.


Perhaps draft-ietf-bess-evpn-overlay could hint on such a Geneve
work for EVPN; something like: "Adapting the EVPN control plane to the
Geneve encapsulation is out of the scope of this document, and is
expected to be covered in a separate document based on the same
architectural principles"


Perfect, thanks!

Is that draft already in the works, or just planned?

Alvaro.



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread Alvaro Retana 
On December 5, 2017 at 9:25:39 AM, thomas.mo...@orange.com (
thomas.mo...@orange.com) wrote:

>
> [...]
>
>
> M8. References
>
>
> M8.1. TUNNEL-ENCAP (aka ) should be
> Normative, which btw is marked to Obsolete rfc5512; I mention this
> because both are listed in several parts, so you should take
> rfc5512 out.
>
>
> This was debated on a while ago, and this is somehow the conclusion of
> the discussion:
>
> https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w
>
> Copy-paste:
> 
> We'll also add idr-tunnel-encaps a Informative reference. With respect
> to Tunnel Encap Extended Community (which is the only part of
> idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft
> itself references RFC 5512.
>
> During the course of WG LC and RFC editorship of evpn-overlay draft, if
> we see that idr-tunnel-encap is progressing fast, then we can drop the
> reference to RFC 5512 and make the reference to idr-tunnel-encap
> Normative. Otherwise, we'll keep both references with RFC 5512 as
> Normative and idr-tunnel-encap as Informative.
> 
>
> The question probably is whether or not idr-tunnel-encap progress is
> sufficient.
>
If anything, both references should at least be of the same type: I can see
no reasoning why one would be Normative and the other Informative.

In this case, idr-tunnel-encap already went through WGLC (according to the
datatracker) — we can’t ignore the fact that idr has consensus on
deprecating rfc5512.  Again, we don’t need both references.



>
>
>
>
> M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE,
> RFC4023
>
>
> My process fu is weakening, but if this specification is standard track
> (and I believe it should be), I believe it can't normatively depend on
> Informative specs and some of the above are in this category.
>
It can if we call the Down References out in the IETF Last Call and no one
opposes.  I think we already processed at least one document with a DownRef
toVXLAN, so I don’t think that’s a problem.

In any case, the type of Reference should be decided based on the real
dependency of the document, not on its status.

Thanks!

Alvaro.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread Ali Sajassi (sajassi) 


Perfect, thanks!

Is that draft already in the works, or just planned?

[Ali] It is already in the works:

https://tools.ietf.org/html/draft-boutros-bess-evpn-geneve-00

Cheers,

Ali

Alvaro.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread Alvaro Retana 
On December 5, 2017 at 9:25:39 AM, thomas.mo...@orange.com (
thomas.mo...@orange.com) wrote:

>
>
> (2) Document Status
>
>
> Why is this a Standards Track document? The Abstract/Introduction
> say
> that “this document describes how Ethernet VPN (EVPN) can be used
> as an
> NVO solution and explores applicability of EVPN functions and
> procedures.” -- if it’s just a description (as the text clearly
> is),
> and not a technical specification, then why it is not
> Informational?
> I can see how we could call it an Applicability Statement (rfc2026)
> and
> still publish it in the Standards Track. If we want to go that
> way, we
> would need some minor updates to make it clear that this is an
> Applicability Statement and is not intended to stand in for a
> Technical
> Specification. I am not clear on the process as it related to
> possible
> DownRefs (see below), but I’m willing to Last Call an Applicability
> Statement in the Standards Track…if that is what you want.
>
>
> Maybe the authors should s/describes/specifies/ to better reflect
> the
> content of the document.
> On the other hand, rfc2026 says "A Technical Specification is any
> description of a protocol, service, procedure, convention, or
> format."
> It seems to match as well.
>
>
> I agree that "specifies" is a better wording for the content of this
> document which does specify detailed procedures combining existing
> mechanisms. It certainly needs to be Standard Track.
>
Ok, that’s fine.

Alvaro.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread thomas.morin 
All,

Martin Vigoureux, 2017-12-05 11:34:
> 
> Alvaro: [...]
> > 
> > What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is
> > focusing on
> > Geneve as the Standard encapsulation, but this document doesn’t
> > even mention it.
> 
> Indeed. But The decision by NVO3 to work on Geneve is fairly recent.
> I have indicated in the BESS report that we'll likely be working
> closeer 
> with NVO3 from now on. An individual draft on the applicability of
> EVPN 
> to NVO3 networks is targeting NVO3 WG. Conversely, an individual
> draft 
> on EVPN extensions for Geneve is targeting BESS. We have agreed that 
> we'll do cross reviews at the important milestones of these docs.

Perhaps draft-ietf-bess-evpn-overlay could hint on such a Geneve
work for EVPN; something like: "Adapting the EVPN control plane to the
Geneve encapsulation is out of the scope of this document, and is
expected to be covered in a separate document based on the same
architectural principles" 


> 
> > (2) Document Status
> > 
> > 
> > Why is this a Standards Track document?  The Abstract/Introduction
> > say
> > that “this document describes how Ethernet VPN (EVPN) can be used
> > as an
> > NVO solution and explores applicability of EVPN functions and
> > procedures.”  -- if it’s just a description (as the text clearly
> > is),
> > and not a technical specification, then why it is not
> > Informational?
> > I can see how we could call it an Applicability Statement (rfc2026)
> > and
> > still publish it in the Standards Track.  If we want to go that
> > way, we
> > would need some minor updates to make it clear that this is an
> > Applicability Statement and is not intended to stand in for a
> > Technical
> > Specification.  I am not clear on the process as it related to
> > possible
> > DownRefs (see below), but I’m willing to Last Call an Applicability
> > Statement in the Standards Track…if that is what you want.
> 
> Maybe the authors should s/describes/specifies/ to better reflect
> the 
> content of the document.
> On the other hand, rfc2026 says "A Technical Specification is any 
> description of a protocol, service, procedure, convention, or
> format."
> It seems to match as well.

I agree that "specifies" is a better wording for the content of this
document which does specify detailed procedures combining existing
mechanisms.  It certainly needs to be Standard Track.



(more comments/answers below)


> > 
> > M2. From 5.1.3 (Constructing EVPN BGP Routes):  as long as they use
> > the
> > same EVPN multi-homing procedures (section 8.3.1, Split Horizon)…”.
> > Is
> > Split Horizon an example, or the only multi-homing procedure that
> > should
> > be considered?  Please be clear.

(Related to this sentence, but not related to your question:)

I recently realized that I'm unclear on this point: the way the MPLS
label fields are decoded is not the same for a VXLAN or NVGRE encap
(where the whole 3 bytes are used) than for an MPLS encap (where only
the topmost 20 bits of the 3 bytes are used). This means that, although
the encoding is unambiguous when one encap is used (or when VXLAN and
NVGRE would be used at the same time), it becomes ambiguous when a mix
is used, for instance MPLS and VXLAN, unless the dataplane MPLS label
to use is equal to the VNI after a 4-bit left shifting.

If I'm not wrong "...routes MAY be advertised with multiple
encapsulation types" needs to be restricted to the cases that work.

[...]
> > 
> > M8. References
> > 
> > 
> > M8.1. TUNNEL-ENCAP (aka ) should be
> > Normative, which btw is marked to Obsolete rfc5512; I mention this
> > because both are listed in several parts, so you should take
> > rfc5512 out.

This was debated on a while ago, and this is somehow the conclusion of
the discussion:

https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w

Copy-paste:

We'll also add idr-tunnel-encaps a Informative reference. With respect
to Tunnel Encap Extended Community (which is the only part of
idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft
itself references RFC 5512.

During the course of WG LC and RFC editorship of evpn-overlay draft, if
we see that idr-tunnel-encap is progressing fast, then we can drop the
reference to RFC 5512 and make the reference to idr-tunnel-encap
Normative. Otherwise, we'll keep both references with RFC 5512 as
Normative and idr-tunnel-encap as Informative.


The question probably is whether or not idr-tunnel-encap progress is
sufficient.


> > 
> > 
> > M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE,
> > RFC4023
> > 

My process fu is weakening, but if this specification is standard track
(and I believe it should be), I believe it can't normatively depend on
Informative specs and some of the above are in this category.

-Thomas
(as document shep)

_

Ce message et ses pieces jointes peuvent contenir

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread Martin Vigoureux 

Hello Alvaro,

thanks for your review.
Please see in-line regarding the two first points.

-m

Le 04/12/2017 à 22:49, Alvaro Retana a écrit :

Dear Authors:

I just finished reading this document (finally!).  I have a some
comments (see below) which I think should be easy to address.

I also have some bigger issues that we’ll need the Chairs’ help to solve:

(1) Coordination with nv03

For the Chairs:  Except for some clarification comments [1] related to
the current version, I see no other traffic in the nvo3 list related to
this document.  Was there some other coordination that I’m missing?   I
am not questioning having this document in bess (that’s perfectly fine);
I’m just raising the needed coordination with other WGs, from the
Charter: "The working group will also coordinate with...NVO3 working
group for coordination of protocols to support data center VPNs.”


What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is focusing on
Geneve as the Standard encapsulation, but this document doesn’t
even mention it.


Indeed. But The decision by NVO3 to work on Geneve is fairly recent.
I have indicated in the BESS report that we'll likely be working closeer 
with NVO3 from now on. An individual draft on the applicability of EVPN 
to NVO3 networks is targeting NVO3 WG. Conversely, an individual draft 
on EVPN extensions for Geneve is targeting BESS. We have agreed that 
we'll do cross reviews at the important milestones of these docs.



(2) Document Status


Why is this a Standards Track document?  The Abstract/Introduction say
that “this document describes how Ethernet VPN (EVPN) can be used as an
NVO solution and explores applicability of EVPN functions and
procedures.”  -- if it’s just a description (as the text clearly is),
and not a technical specification, then why it is not Informational?



I can see how we could call it an Applicability Statement (rfc2026) and
still publish it in the Standards Track.  If we want to go that way, we
would need some minor updates to make it clear that this is an
Applicability Statement and is not intended to stand in for a Technical
Specification.  I am not clear on the process as it related to possible
DownRefs (see below), but I’m willing to Last Call an Applicability
Statement in the Standards Track…if that is what you want.


Maybe the authors should s/describes/specifies/ to better reflect the 
content of the document.
On the other hand, rfc2026 says "A Technical Specification is any 
description of a protocol, service, procedure, convention, or format."

It seems to match as well.





Thanks!


Alvaro.




[1]
https://mailarchive.ietf.org/arch/msg/nvo3/cd0hOfb966ROcL4t8JCrBD28bBg/?qid=c9f632dc5d6aab5e4b22972bb242baf0




Major:


M1. Section 5.1.2.1 (Auto Derivation of RT) shows a “packet format” to
illustrate how the RT can be auto-derived.  Without any context, the
description doesn’t make much sense: the fields are not described in
order, the reader is expected to know about global and
local administrative fields, the “A-bit” (or the Type field) are not
mentioned in the description, people could probably guess that “D-ID”
means “domain-id”, there’s no indication of what to do with that “packet
format”, etc.  Please clean the description up, include clearer
explanations and some references can’t hurt.


M1.2. What about 4-byte ASNs?



M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be
advertised with multiple encapsulation types as long as they use the
same EVPN multi-homing procedures (section 8.3.1, Split Horizon)…”. Is
Split Horizon an example, or the only multi-homing procedure that should
be considered?  Please be clear.



M3. From 5.2 (MPLS over GRE):


M3.1. “...when it is used in conjunction with EVPN the GRE key field
SHOULD be present, and SHOULD be used to provide a 32-bit entropy
field.”  What are the cases when it is ok not to include the field, or
use it for that purpose?  IOW, why are these SHOULDs not MUSTs?  Or
maybe, when is the key field needed?


M3.2. "The Checksum and Sequence Number fields are not needed and their
corresponding C and S bits MUST be set to zero.”  This is different than
what rfc4023 specifies (not a problem).  If you’re specifying the
setting of the bits, then you should be more prescriptive with whether
the fields are included of not; suggestion: "The Checksum and Sequence
Number fields MUST NOT be included and the corresponding C and S bits in
the GRE Packet Header MUST be set to zero.”



M4. In 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE
Encapsulation)


M4.1. These 2 MUSTs seem out of place as they are used to explain, and
not in a Normative way: “ ..the RD must be a unique value per EVI or per
NVE as described in [RFC7432]. In other words, whenever there is more
than one administrative domain for global VNI, then a unique RD MUST
be used, or whenever the VNI value have local significance, then
a unique RD MUST be used.”  s/MUST/must


M4.2. This SHOULD is also out of place

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-04 Thread John E Drake 
Alvaro,

Comments inline.

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Alvaro Retana
Sent: Monday, December 4, 2017 4:49 PM
To: bess-cha...@ietf.org
Cc: EXT - thomas.mo...@orange.com <thomas.mo...@orange.com>; bess@ietf.org
Subject: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

Dear Authors:

I just finished reading this document (finally!).  I have a some comments (see 
below) which I think should be easy to address.

I also have some bigger issues that we’ll need the Chairs’ help to solve:

(1) Coordination with nv03

For the Chairs:  Except for some clarification comments [1] related to the 
current version, I see no other traffic in the nvo3 list related to this 
document.  Was there some other coordination that I’m missing?   I am not 
questioning having this document in bess (that’s perfectly fine); I’m just 
raising the needed coordination with other WGs, from the Charter: "The working 
group will also coordinate with...NVO3 working group for coordination of 
protocols to support data center VPNs.”

[JD]  This draft had been around for nearly five years and the coordination 
happened a long time ago.  Because NVO3 was not chartered to work on a control 
plane, the coordination was mainly to ensure that this draft met the 
requirements specified by that group.


What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is focusing on Geneve 
as the Standard encapsulation, but this document doesn’t even mention it.

[JD]  There is a separate draft for Geneve.

(2) Document Status

Why is this a Standards Track document?  The Abstract/Introduction say that 
“this document describes how Ethernet VPN (EVPN) can be used as an NVO solution 
and explores applicability of EVPN functions and procedures.”  -- if it’s just 
a description (as the text clearly is), and not a technical specification, then 
why it is not Informational?

[JD]  We define new code points for encapsulation, we define how EVPN labels 
are carried in the VXLAN and NVGRE encapsulations, and we define alternate 
multi-homing procedures for both split horizon and mass-withdraw.  We also 
define which EVPN routes and procedures are applicable when the CE & PE are 
collocated in a VM.  (I’ve probably missed a few things.)

I can see how we could call it an Applicability Statement (rfc2026) and still 
publish it in the Standards Track.  If we want to go that way, we would need 
some minor updates to make it clear that this is an Applicability Statement and 
is not intended to stand in for a Technical Specification.  I am not clear on 
the process as it related to possible DownRefs (see below), but I’m willing to 
Last Call an Applicability Statement in the Standards Track…if that is what you 
want.


Thanks!

Alvaro.


[1] 
https://mailarchive.ietf.org/arch/msg/nvo3/cd0hOfb966ROcL4t8JCrBD28bBg/?qid=c9f632dc5d6aab5e4b22972bb242baf0<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_nvo3_cd0hOfb966ROcL4t8JCrBD28bBg_-3Fqid-3Dc9f632dc5d6aab5e4b22972bb242baf0=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=mKJTroxeKwUW5Dz0wIXlyEsRpF3mTI9Cx3Lr7BnoimQ=_nhO55F4ZyOeH1wQYIJdhaP3mZgVJyJaWwaPy1uirtk=>



Major:

M1. Section 5.1.2.1 (Auto Derivation of RT) shows a “packet format” to 
illustrate how the RT can be auto-derived.  Without any context, the 
description doesn’t make much sense: the fields are not described in order, the 
reader is expected to know about global and local administrative fields, the 
“A-bit” (or the Type field) are not mentioned in the description, people could 
probably guess that “D-ID” means “domain-id”, there’s no indication of what to 
do with that “packet format”, etc.  Please clean the description up, include 
clearer explanations and some references can’t hurt.

M1.2. What about 4-byte ASNs?


M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be advertised 
with multiple encapsulation types as long as they use the same EVPN 
multi-homing procedures (section 8.3.1, Split Horizon)…”. Is Split Horizon an 
example, or the only multi-homing procedure that should be considered?  Please 
be clear.


M3. From 5.2 (MPLS over GRE):

M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD be 
present, and SHOULD be used to provide a 32-bit entropy field.”  What are the 
cases when it is ok not to include the field, or use it for that purpose?  IOW, 
why are these SHOULDs not MUSTs?  Or maybe, when is the key field needed?

M3.2. "The Checksum and Sequence Number fields are not needed and their 
corresponding C and S bits MUST be set to zero.”  This is different than what 
rfc4023 specifies (not a problem).  If you’re specifying the setting of the 
bits, then you should be more prescriptive with whether the fields are included 
of not; suggestion: "The Checksum and Sequence Number fields MUST NOT be 
included and the corresponding C and S bits in the

[bess] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-04 Thread Alvaro Retana 
Dear Authors:

I just finished reading this document (finally!).  I have a some comments
(see below) which I think should be easy to address.

I also have some bigger issues that we’ll need the Chairs’ help to solve:

(1) Coordination with nv03

For the Chairs:  Except for some clarification comments [1] related to the
current version, I see no other traffic in the nvo3 list related to this
document.  Was there some other coordination that I’m missing?   I am not
questioning having this document in bess (that’s perfectly fine); I’m just
raising the needed coordination with other WGs, from the Charter: "The
working group will also coordinate with...NVO3 working group for coordination
of protocols to support data center VPNs.”


What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is focusing on
Geneve as the Standard encapsulation, but this document doesn’t
even mention it.




(2) Document Status


Why is this a Standards Track document?  The Abstract/Introduction say that
“this document describes how Ethernet VPN (EVPN) can be used as an NVO
solution and explores applicability of EVPN functions and procedures.”  --
if it’s just a description (as the text clearly is), and not a technical
specification, then why it is not Informational?


I can see how we could call it an Applicability Statement (rfc2026) and
still publish it in the Standards Track.  If we want to go that way, we
would need some minor updates to make it clear that this is an
Applicability Statement and is not intended to stand in for a Technical
Specification.  I am not clear on the process as it related to possible
DownRefs (see below), but I’m willing to Last Call an Applicability
Statement in the Standards Track…if that is what you want.



Thanks!


Alvaro.




[1]
https://mailarchive.ietf.org/arch/msg/nvo3/cd0hOfb966ROcL4t8JCrBD28bBg/?qid=c9f632dc5d6aab5e4b22972bb242baf0



Major:


M1. Section 5.1.2.1 (Auto Derivation of RT) shows a “packet format” to
illustrate how the RT can be auto-derived.  Without any context, the
description doesn’t make much sense: the fields are not described in order,
the reader is expected to know about global and local administrative
fields, the “A-bit” (or the Type field) are not mentioned in the
description, people could probably guess that “D-ID” means “domain-id”,
there’s no indication of what to do with that “packet format”, etc.  Please
clean the description up, include clearer explanations and some references
can’t hurt.


M1.2. What about 4-byte ASNs?



M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be
advertised with
multiple encapsulation types as long as they use the same EVPN multi-homing
procedures (section 8.3.1, Split Horizon)…”. Is Split Horizon an example,
or the only multi-homing procedure that should be considered?  Please be
clear.



M3. From 5.2 (MPLS over GRE):


M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD
be present, and SHOULD be used to provide a 32-bit entropy field.”  What
are the cases when it is ok not to include the field, or use it for that
purpose?  IOW, why are these SHOULDs not MUSTs?  Or maybe, when is the key
field needed?


M3.2. "The Checksum and Sequence Number fields are not needed and their
corresponding C and S bits MUST be set to zero.”  This is different than
what rfc4023 specifies (not a problem).  If you’re specifying the setting
of the bits, then you should be more prescriptive with whether the fields
are included of not; suggestion: "The Checksum and Sequence Number fields
MUST NOT be included and the corresponding C and S bits in the GRE Packet
Header MUST be set to zero.”



M4. In 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE
Encapsulation)


M4.1. These 2 MUSTs seem out of place as they are used to explain, and not
in a Normative way: “ ..the RD must be a unique value per EVI or per
NVE as described
in [RFC7432]. In other words, whenever there is more than one
administrative domain for global VNI, then a unique RD MUST be used, or
whenever the VNI value have local significance, then a unique RD MUST be
used.”  s/MUST/must


M4.2. This SHOULD is also out of place because the standardization was
already done in rfc7432 (this document is just mentioning it): “...as noted
in section 8.6 of [RFC7432]...the single-homing ingress NVE SHOULD be able
to…”. s/SHOULD/should


M4.3. Section 10.2.1 then points back at the text in 7.1 using another
SHOULD…again, s/SHOULD/should



M5. 7.2 (Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation) also
includes a superfluous SHOULD: “...as noted in section 8.6 of [RFC7432]...a
single-homing ingress NVE SHOULD implement…”.  s/SHOULD/should



M6. The introductory paragraph in Section 8.1 (EVPN Multi-Homing Features)
says that it is used to "recap the multi-homing features of EVPN to highlight
the encapsulation dependencies. The section only describes the features and
functions at a high-level. For more details, the reader is to refer to
[RFC7432].”