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

[<[e-mail]>]

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.