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
