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

[<[e-mail]>]

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