John, It's clear, great thanks. Yes, it's needed in order to distinguish between an advertising node that only support non-MPLS encapsulations and one that supports MPLS and non-MPLS encapsulations. If has no this MPLS encapsulation type, the node that supports MPLS and non-MPLS encapsulations will deemed to be the node that only support non-MPLS encapsulations by remote EVPN PEs.
Thanks, weiguo ________________________________ From: John E Drake [[email protected]] Sent: Wednesday, November 11, 2015 22:39 To: Haoweiguo; Rabadan, Jorge (Jorge); [email protected] Cc: [email protected] Subject: RE: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' Weiguo, 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. Yours Irrespectively, John 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
