Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT)

[John E Drake <[e-mail]>]

Sami,

I don't think we want to use a global VNI because if we do we will be limited to one circuit per global VNI due to the fact that we demux traffic strictly using the label value and not the MAC address.

Yours Irrespectively,

John


> -----Original Message-----
> From: Alvaro Retana (aretana) [mailto:[e-mail]]
> Sent: Wednesday, April 12, 2017 3:49 PM
> To: Sami Boutros <[e-mail]>; Alia Atlas <[e-mail]>;
> The IESG <[e-mail]>
> Cc: [e-mail]; Jeffrey (Zhaohui) Zhang
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS
> and COMMENT)
> 
> Sami:
> 
> Hi!
> 
> Let’s go ahead and add the text to explain the operation with VXLAN – I think
> that the reference to rfc7348 should be Normative.
> 
> I’ll take care of dealing with the downref when we’re ready with the new text.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> 
> 
> 
> On 4/12/17, 2:14 PM, "Sami Boutros" <[e-mail]> wrote:
> 
> Hi Alia,
> 
> Please see comments inline.
> 
> 
> On 4/11/17, 4:43 PM, "Alia Atlas" <[e-mail]> wrote:
> 
> >Alia Atlas has entered the following ballot position for
> >draft-ietf-bess-evpn-vpws-11: Discuss
> >
> >When responding, please keep the subject line intact and reply to all
> >email addresses included in the To and CC lines. (Feel free to cut this
> >introductory paragraph, however.)
> >
> >
> >Please refer to
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_
> >statement_discuss-
> 2Dcriteria.html&d=DwICaQ&c=uilaK90D4TOVoH58JNXRgQ&r=I
> >VzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=78sPNErI-
> rljSFAaM5b76_QaDS
> >Tz2BD_8ny0Dxcf4sM&s=s8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoOr2I&e
> =
> >for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> >The document, along with other ballot positions, can be found here:
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
> >rg_doc_draft-2Dietf-2Dbess-2Devpn-
> 2Dvpws_&d=DwICaQ&c=uilaK90D4TOVoH58JN
> >XRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=78sPNErI-
> rljSFAaM5
> >b76_QaDSTz2BD_8ny0Dxcf4sM&s=MlJKXisQTr1aheS8hahty-
> iFDOCS_GhM37X2lMUAH54
> >&e=
> >
> >
> >
> >----------------------------------------------------------------------
> >DISCUSS:
> >----------------------------------------------------------------------
> >
> >First, thank you for a clearly written document that contained enough
> >context to trigger my hazy memory of some of the technical details.
> >
> >My concern is around this paragraph in the Introduction:
> >
> >"The MPLS label value in the Ethernet A-D route can be set to the
> >   VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may
> >have
> >   a global scope or local scope per PE and may also be equal to the
> >   VPWS service instance identifier set in the Ethernet A-D route.
> >"
> >
> >First, I recognize that folks have implemented and deployed EVPN with
> >VXLAN.
> >That's fine.  There is an ISE RFC 7348 that describes VXLAN.   Depending
> >on what
> >you (authors, shepherd, AD, WG) decide to do about the rest of my
> >concern, it is likely that this should be normative references - which
> >would be a downref.
> 
> I can add the 7348 as a normative reference.
> 
> >
> >Second, the paragraph here isn't really adequate to describe how to
> >implement the
> >functionality.   I don't see how:
> >    a) The ingress PE decides which VNIs it can send based upon the
> >VNI=MPLS_label
> >        from the egress.   Is there an assumption that VXLAN allows
> >sending all VNIs across
> >        the particular VPWS, whether port-based, VLAN-based, etc?
> 
> We are signaling Ethernet A-D route per VPWS instance, and in there we will
> signal VNI instead of an MPLS label for VxLAN encap.
> 
> >    b) Is there an assumption that the egress PE-advertised MPLS label
> >also indicates the
> >         VNI to be used?
> 
> EVPN can work with different encapsulations a BGP Tunnel Encapsulation
> Attribute That specifies the tunnel type will be added to the Ethernet A-D route.
> 
> 
> >That seems like another mode, like the
> >VLAN-based service, except
> >         it is perhaps VNI + VLAN-based service?
> 
> The draft lists clearly the different service interface types, and there will
> be only one VNI per VPWS instance wether this is Vlan or port based.
> 
> >
> >Please don't take this Discuss as a reason to remove the paragraph and
> >the implied functionality.
> >If it's implemented and deployed (and I think it is) - then what I really
> >want is to just have it
> >adequately written down so that others can interoperably implement.  The
> >downref to VXLAN
> >should just be a matter of process nuisance (i.e. another IETF Last Call
> >and handling any concerns).
> >
> 
> Should I add the 7348 as a normative reference?
> 
> 
> 
> >
> >----------------------------------------------------------------------
> >COMMENT:
> >----------------------------------------------------------------------
> >
> >1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or
> >"This specification" or...
> 
> Will fix.
> >
> >2) Sec 3.1:  "    C      If set to 1, a Control word [RFC4448] MUST be
> >present when sending EVPN packets to this PE."
> >   Given discussions with IEEE about real MACs starting with 4 and 6 in
> >top nibble, adding a statement about it being BCP to include
> >   the control word (unless using Entropy Label) would be a good idea.
> >
> Could you suggest some text?
> 
> Should I submit -12 with the changes?
> 
> Thanks,
> 
> Sami
> >
>