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