Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

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

Thomas (and copying Eric),

Why do you think it should be documented in Eric's draft rather than in the EVPN Overlay draft?

Yours Irrespectively,

John

> -----Original Message-----
> From: BESS [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Thursday, November 12, 2015 3:39 AM
> To: [e-mail]
> Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
> 
> HI John, Weiguo,
> 
> John E Drake :
> >
> > It is needed in order to distinguish between an advertising node that
> > only supports non-MPLS encapsulations and one that supports MPLS and
> > non-MPLS encapsulations.  An advertising node that only supports MPLS
> > encapsulation does not need to advertise anything.
> >
> 
> By the way, I suggested this to be documented in draft-rosen-idr-tunnel-
> encaps [1].
> 
> Best,
> 
> -Thomas
> 
> [1] http://www.ietf.org/mail-archive/web/idr/current/msg14732.html
> 
> 
> > *From:*Haoweiguo [mailto:[e-mail]]
> > *Sent:* Wednesday, November 11, 2015 1:08 AM
> > *To:* Rabadan, Jorge (Jorge); [e-mail]; John E Drake
> > *Cc:* [e-mail]
> > *Subject:* RE: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
> >
> > Jorge,
> >
> > Understood, many thanks. Now that the default tunnel encapsulation is
> > MPLS encapsulation, the tunnel type 10 seems to be unneccessary. So is
> > the introduction of tunnel type 10 just for further removing
> > ambiguity? If i don't use the tunnel type 10 in MPLS based EVPN
> > implementation(RFC 7432), it will also never incur any issue. Am i right?
> >
> > Thanks,
> >
> > weiguo
> >
> > ----------------------------------------------------------------------
> > --
> >
> > *From:*BESS [[e-mail]] on behalf of Rabadan, Jorge
> > (Jorge) [[e-mail]]
> > *Sent:* Wednesday, November 11, 2015 11:47
> > *To:* Haoweiguo; [e-mail] <mailto:[e-mail]>;
> > [e-mail] <mailto:[e-mail]>
> > *Cc:* [e-mail] <mailto:[e-mail]>
> > *Subject:* Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
> >
> > Weiguo,
> >
> > Well, if an RFC7432 implementation does not use the RFC5512 ext
> > community, the following sentence in the evan-overlay draft should
> > help interoperability. I personally don’t see any issues.
> >
> > If the BGP Encapsulation extended community is not present, then the
> >    default MPLS encapsulation or a statically configured encapsulation
> >    is assumed.
> >
> > Thanks.
> >
> > Jorge
> >
> > *From: *Haoweiguo <[e-mail]
> <mailto:[e-mail]>>
> > *Date: *Tuesday, November 10, 2015 at 7:03 PM
> > *To: *Jorge Rabadan <[e-mail]
> > <mailto:[e-mail]>>, "[e-mail]
> > <mailto:[e-mail]>" <[e-mail]
> > <mailto:[e-mail]>>, "[e-mail]
> > <mailto:[e-mail]>" <[e-mail]
> > <mailto:[e-mail]>>
> > *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
> > <mailto:[e-mail]>>
> > *Subject: *RE: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
> >
> >     Jorge,
> >
> >     Thanks for your explanations. However, i still can't understand,
> >     i'm sorry.
> >
> >     RFC 5512 only defines IP tunnel type and encapsulation attribute,
> >     like L2TPv3,GRE and IP in IP.  For RFC 5512, MPLS tunnel doesn't
> >     need to be defined specifically, it is default case. In RFC 7432,
> >     the tunnel type 10 also hasn't been defined. Later, when the EVPN
> >     for overlay network solution was proposed, the tunnel type 10 was
> >     introduced to differentiate MPLS tunnel and VXLAN/NVGRE/MPLS Over
> >     GRE tunnel, because same route type 1,2,3,4 and 5 are used in both
> >     RFC 7432 and the draft 'draft-ietf-bess-evpn-overlay-02'. We need
> >     the tunnel type to clearly notify peer EVPN PE which
> >     tunnel(including MPLS tunnel type) should be used.  So it
> >     introduced updates on RFC 7432 and will incur some interoperbility
> >     issue for RFC 7432. Am i right?
> >
> >     Thanks,
> >
> >     weiguo
> >
> >
> > ----------------------------------------------------------------------
> > --
> >
> >     *From:*BESS [[e-mail] <mailto:[e-mail]>]
> >     on behalf of Rabadan, Jorge (Jorge)
> >     [[e-mail]
> >     <mailto:[e-mail]>]
> >     *Sent:* Wednesday, November 11, 2015 0:01
> >     *To:* Haoweiguo; [e-mail] <mailto:[e-mail]>;
> >     [e-mail] <mailto:[e-mail]>
> >     *Cc:* [e-mail] <mailto:[e-mail]>
> >     *Subject:* Re: [bess] One question about
> >     'draft-ietf-bess-evpn-overlay-02'
> >
> >     Weiguo,
> >
> >     There are already implementations using value 10 in the RFC5512
> >     BGP encap ext community.
> >
> >     That is the value you would have in RFC7432 compliant networks
> >     where you can also have overlay tunnels. Value 10 would indicate
> >     to the ingress PE that the route needs an MPLS tunnel to be resolved.
> >
> >     Thx
> >
> >     Jorge
> >
> >     *From: *BESS <[e-mail]
> >     <mailto:[e-mail]>> on behalf of Haoweiguo
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Date: *Tuesday, November 10, 2015 at 1:05 AM
> >     *To: *"[e-mail] <mailto:[e-mail]>"
> >     <[e-mail] <mailto:[e-mail]>>,
> >     "[e-mail] <mailto:[e-mail]>"
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Subject: *[bess] One question about 'draft-ietf-bess-evpn-overlay-02'
> >
> >         Hi Ali & John,
> >
> >         The draft of 'draft-ietf-bess-evpn-overlay-02' describes how
> >         EVPN can be used for Overlay network, the overlay network
> >         includes VXLAN, NVGRE and MPLS Over GRE.
> >
> >         In section 13 IANA considerations, several overlay tunnel
> >         types are requested as follows:
> >
> >         8 VXLAN Encapsulation
> >         9    NVGRE Encapsulation
> >         10   MPLS Encapsulation   (?)
> >         11   MPLS in GRE Encapsulation
> >         12   VXLAN GPE Encapsulation
> >
> >         IMO, 8,9,11 and 12 are all overlay encapsulations, 10 is an
> >         exception. Would you like to explain what's the purpose of
> >         tunnel type 10?
> >
> >         Thanks,
> >
> >         weiguo
> >
> >
> >
> > _______________________________________________
> > BESS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bess
> 
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess