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:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, November 12, 2015 3:39 AM > To: [email protected] > 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:[email protected]] > > *Sent:* Wednesday, November 11, 2015 1:08 AM > > *To:* Rabadan, Jorge (Jorge); [email protected]; John E Drake > > *Cc:* [email protected] > > *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 [[email protected]] on behalf of Rabadan, Jorge > > (Jorge) [[email protected]] > > *Sent:* Wednesday, November 11, 2015 11:47 > > *To:* Haoweiguo; [email protected] <mailto:[email protected]>; > > [email protected] <mailto:[email protected]> > > *Cc:* [email protected] <mailto:[email protected]> > > *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 <[email protected] > <mailto:[email protected]>> > > *Date: *Tuesday, November 10, 2015 at 7:03 PM > > *To: *Jorge Rabadan <[email protected] > > <mailto:[email protected]>>, "[email protected] > > <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>>, "[email protected] > > <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > *Cc: *"[email protected] <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > *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 [[email protected] <mailto:[email protected]>] > > on behalf of Rabadan, Jorge (Jorge) > > [[email protected] > > <mailto:[email protected]>] > > *Sent:* Wednesday, November 11, 2015 0:01 > > *To:* Haoweiguo; [email protected] <mailto:[email protected]>; > > [email protected] <mailto:[email protected]> > > *Cc:* [email protected] <mailto:[email protected]> > > *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 <[email protected] > > <mailto:[email protected]>> on behalf of Haoweiguo > > <[email protected] <mailto:[email protected]>> > > *Date: *Tuesday, November 10, 2015 at 1:05 AM > > *To: *"[email protected] <mailto:[email protected]>" > > <[email protected] <mailto:[email protected]>>, > > "[email protected] <mailto:[email protected]>" > > <[email protected] <mailto:[email protected]>> > > *Cc: *"[email protected] <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > *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 > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
