Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00
Hi John, Since the tunnel encap draft goes with encap tunnel attribute and there was no deployment of RFC5512, IMO, we should deprecate encapsulation extended community to keep a consistent method. Thus, should the overlay draft states if BGP tunnel encapsulate attribute is not present, Regards, Lucy -Original Message- From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of thomas.mo...@orange.com Sent: Friday, November 13, 2015 10:46 AM To: John E Drake; bess@ietf.org Cc: IDR; Ali Sajassi (sajassi); Eric Rosen Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00 John, (Cc'ing IDR.) 2015-11-13, John E Drake: > > I spoke with Eric and Ali and we would like to change both the overlay > draft and the tunnel encaps drafts as follows. > > For the overlay draft, replace this text in section 5.1.3: > > "If the BGP Encapsulation extended community is not present, then > thedefault MPLS encapsulation or a statically configured encapsulation > is > assumed." > > With the following: > > "Note that the MPLS encapsulation tunnel type 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 any encapsulation tunnel types; i.e., if the BGP > Encapsulation extended community is not present, then either MPLS > encapsulation or a statically configured encapsulation is assumed." Having more text to explain things in the overlay draft does not hurt. > > For the tunnel encaps draft, replace this text in section 5: > > "If the Tunnel Encapsulation attribute contains several TLVs (i.e., > ifit specifies several tunnels), router R may choose any one of those > tunnels, based upon local policy. If any of tunnels' TLVs contain the > > Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the > choice of tunnel may be influenced by these sub-TLVs." > > With the following: > > "If the Tunnel Encapsulation attribute contains several TLVs (i.e., > ifit specifies several tunnels), router R may choose any one of those > tunnels, based upon local policy. If any of tunnels' TLVs contain the > Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], > the choice of tunnel may be influenced by these sub-TLVs. Note that if > none of the TLVs specifies the MPLS tunnel type, a Label Switched Path > SHOULD NOT be used unless none of the TLVs specifies a feasible tunnel." I think that the above will technically work. *However* it would be a pity to *not* have the very useful clear-text explanation of the reason for the 'MPLS' type (what you propose to add above in the overlay draft) in draft-ietf-idr-tunnel-encaps-00... why provide the smooth explanation for only one of the specs to which this 'MPLS' type applies ? > > We hope this is satisfactory. Close, but not quite there yet :) Best, -Thomas > >> -Original Message----- >> From: Thomas Morin [mailto:thomas.mo...@orange.com] >> Sent: Thursday, November 12, 2015 10:08 AM >> To: John E Drake; bess@ietf.org >> Cc: Eric Rosen >> Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' >> >> Hi John, >> >> 2015-11-12, John E Drake: >>> >>> Why do you think it should be documented in Eric's draft rather than >>> in the >> EVPN Overlay draft? >> >> The issue applies beyond the context of E-VPN overlay specs, and >> exist in any context where different kinds of MPLS(/x) encaps can be >> mixed (E-VPN non-overlay, IP VPNs), which is addressed by Eric's draft. >> >> Best, >> >> -Thomas > _ 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00
John, (Cc'ing IDR.) 2015-11-13, John E Drake: I spoke with Eric and Ali and we would like to change both the overlay draft and the tunnel encaps drafts as follows. For the overlay draft, replace this text in section 5.1.3: "If the BGP Encapsulation extended community is not present, then thedefault MPLS encapsulation or a statically configured encapsulation is > assumed." With the following: "Note that the MPLS encapsulation tunnel type 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 any encapsulation tunnel types; i.e., if the BGP Encapsulation extended community is not present, then either MPLS encapsulation or a statically configured encapsulation is assumed." Having more text to explain things in the overlay draft does not hurt. For the tunnel encaps draft, replace this text in section 5: "If the Tunnel Encapsulation attribute contains several TLVs (i.e., ifit specifies several tunnels), router R may choose any one of those > tunnels, based upon local policy. If any of tunnels' TLVs contain the > Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the choice of tunnel may be influenced by these sub-TLVs." With the following: "If the Tunnel Encapsulation attribute contains several TLVs (i.e., ifit specifies several tunnels), router R may choose any one of those tunnels, based upon local policy. If any of tunnels' TLVs contain the Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the choice of tunnel may be influenced by these sub-TLVs. Note that if none of the TLVs specifies the MPLS tunnel type, a Label Switched Path SHOULD NOT be used unless none of the TLVs specifies a feasible tunnel." I think that the above will technically work. *However* it would be a pity to *not* have the very useful clear-text explanation of the reason for the 'MPLS' type (what you propose to add above in the overlay draft) in draft-ietf-idr-tunnel-encaps-00... why provide the smooth explanation for only one of the specs to which this 'MPLS' type applies ? We hope this is satisfactory. Close, but not quite there yet :) Best, -Thomas -Original Message- From: Thomas Morin [mailto:thomas.mo...@orange.com] Sent: Thursday, November 12, 2015 10:08 AM To: John E Drake; bess@ietf.org Cc: Eric Rosen Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' Hi John, 2015-11-12, John E Drake: Why do you think it should be documented in Eric's draft rather than in the EVPN Overlay draft? The issue applies beyond the context of E-VPN overlay specs, and exist in any context where different kinds of MPLS(/x) encaps can be mixed (E-VPN non-overlay, IP VPNs), which is addressed by Eric's draft. Best, -Thomas _ 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
Thomas, I spoke with Eric and Ali and we would like to change both the overlay draft and the tunnel encaps drafts as follows. For the overlay draft, replace this text in section 5.1.3: "If the BGP Encapsulation extended community is not present, then the default MPLS encapsulation or a statically configured encapsulation is assumed." With the following: "Note that the MPLS encapsulation tunnel type 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 any encapsulation tunnel types; i.e., if the BGP Encapsulation extended community is not present, then either MPLS encapsulation or a statically configured encapsulation is assumed." For the tunnel encaps draft, replace this text in section 5: "If the Tunnel Encapsulation attribute contains several TLVs (i.e., if it specifies several tunnels), router R may choose any one of those tunnels, based upon local policy. If any of tunnels' TLVs contain the Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the choice of tunnel may be influenced by these sub-TLVs." With the following: "If the Tunnel Encapsulation attribute contains several TLVs (i.e., if it specifies several tunnels), router R may choose any one of those tunnels, based upon local policy. If any of tunnels' TLVs contain the Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the choice of tunnel may be influenced by these sub-TLVs. Note that if none of the TLVs specifies the MPLS tunnel type, a Label Switched Path SHOULD NOT be used unless none of the TLVs specifies a feasible tunnel." We hope this is satisfactory. Yours Irrespectively, John > -Original Message- > From: Thomas Morin [mailto:thomas.mo...@orange.com] > Sent: Thursday, November 12, 2015 10:08 AM > To: John E Drake; bess@ietf.org > Cc: Eric Rosen > Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' > > Hi John, > > 2015-11-12, John E Drake: > > > > Why do you think it should be documented in Eric's draft rather than in the > EVPN Overlay draft? > > The issue applies beyond the context of E-VPN overlay specs, and exist in > any context where different kinds of MPLS(/x) encaps can be mixed (E-VPN > non-overlay, IP VPNs), which is addressed by Eric's draft. > > Best, > > -Thomas ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
Hi John,
2015-11-12, John E Drake:
Why do you think it should be documented in Eric's draft rather than in the
EVPN Overlay draft?
The issue applies beyond the context of E-VPN overlay specs, and exist
in any context where different kinds of MPLS(/x) encaps can be mixed
(E-VPN non-overlay, IP VPNs), which is addressed by Eric's draft.
Best,
-Thomas
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of
thomas.mo...@orange.com
Sent: Thursday, November 12, 2015 3:39 AM
To: bess@ietf.org
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:haowei...@huawei.com]
*Sent:* Wednesday, November 11, 2015 1:08 AM
*To:* Rabadan, Jorge (Jorge); saja...@cisco.com; John E Drake
*Cc:* bess@ietf.org
*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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge
(Jorge) [jorge.raba...@alcatel-lucent.com]
*Sent:* Wednesday, November 11, 2015 11:47
*To:* Haoweiguo; saja...@cisco.com <mailto:saja...@cisco.com>;
jdr...@juniper.net <mailto:jdr...@juniper.net>
*Cc:* bess@ietf.org <mailto:bess@ietf.org>
*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
<mailto:haowei...@huawei.com>>
*Date: *Tuesday, November 10, 2015 at 7:03 PM
*To: *Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com
<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net
<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>>
*Cc: *"bess@ietf.org <mailto:bess@ietf.org>" mailto:bess@ietf.org>>
*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 [bess-boun...@ietf.org <mailto:bess-boun...@ietf.org>]
on behalf of Rabadan, Jorge (Jorge)
[jorge.raba...@alcatel-lucent.com
<mailto:jorge.raba...@alcatel-lucent.com>]
*Sent:* Wednesday, November 11, 2015 0:01
*To:* Haoweiguo; saja...@cisco.com <mailto:saja...@cisco.com>;
jdr...@juniper.net <mailto:jdr...@juniper.net>
*Cc:* bess@ietf.org <mailto:bess@ietf.org>
*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 ne
Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
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:bess-boun...@ietf.org] On Behalf Of > thomas.mo...@orange.com > Sent: Thursday, November 12, 2015 3:39 AM > To: bess@ietf.org > 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:haowei...@huawei.com] > > *Sent:* Wednesday, November 11, 2015 1:08 AM > > *To:* Rabadan, Jorge (Jorge); saja...@cisco.com; John E Drake > > *Cc:* bess@ietf.org > > *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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge > > (Jorge) [jorge.raba...@alcatel-lucent.com] > > *Sent:* Wednesday, November 11, 2015 11:47 > > *To:* Haoweiguo; saja...@cisco.com <mailto:saja...@cisco.com>; > > jdr...@juniper.net <mailto:jdr...@juniper.net> > > *Cc:* bess@ietf.org <mailto:bess@ietf.org> > > *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 <mailto:haowei...@huawei.com>> > > *Date: *Tuesday, November 10, 2015 at 7:03 PM > > *To: *Jorge Rabadan > <mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com > > <mailto:saja...@cisco.com>" > <mailto:saja...@cisco.com>>, "jdr...@juniper.net > > <mailto:jdr...@juniper.net>" > <mailto:jdr...@juniper.net>> > > *Cc: *"bess@ietf.org <mailto:bess@ietf.org>" > <mailto:bess@ietf.org>> > > *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 [bess-boun...@ietf.org <mailto:bess-boun...@ietf.org>] > > on behalf of Rabad
Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
Weiguo, You're welcome. Yours Irrespectively, John From: Haoweiguo [mailto:haowei...@huawei.com] Sent: Wednesday, November 11, 2015 8:17 PM To: John E Drake; Rabadan, Jorge (Jorge); saja...@cisco.com Cc: bess@ietf.org Subject: RE: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' 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 [jdr...@juniper.net] Sent: Wednesday, November 11, 2015 22:39 To: Haoweiguo; Rabadan, Jorge (Jorge); saja...@cisco.com<mailto:saja...@cisco.com> Cc: bess@ietf.org<mailto:bess@ietf.org> 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:haowei...@huawei.com] Sent: Wednesday, November 11, 2015 1:08 AM To: Rabadan, Jorge (Jorge); saja...@cisco.com<mailto:saja...@cisco.com>; John E Drake Cc: bess@ietf.org<mailto:bess@ietf.org> 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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com] Sent: Wednesday, November 11, 2015 11:47 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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 mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 7:03 PM To: Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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 [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>] Sent: Wednesday, November 11, 2015 0:01 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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
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:haowei...@huawei.com]
*Sent:* Wednesday, November 11, 2015 1:08 AM
*To:* Rabadan, Jorge (Jorge); saja...@cisco.com; John E Drake
*Cc:* bess@ietf.org
*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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge
(Jorge) [jorge.raba...@alcatel-lucent.com]
*Sent:* Wednesday, November 11, 2015 11:47
*To:* Haoweiguo; saja...@cisco.com <mailto:saja...@cisco.com>;
jdr...@juniper.net <mailto:jdr...@juniper.net>
*Cc:* bess@ietf.org <mailto:bess@ietf.org>
*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 mailto:haowei...@huawei.com>>
*Date: *Tuesday, November 10, 2015 at 7:03 PM
*To: *Jorge Rabadan <mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com
<mailto:saja...@cisco.com>" <mailto:saja...@cisco.com>>, "jdr...@juniper.net
<mailto:jdr...@juniper.net>" <mailto:jdr...@juniper.net>>
*Cc: *"bess@ietf.org <mailto:bess@ietf.org>" <mailto:bess@ietf.org>>
*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 [bess-boun...@ietf.org <mailto:bess-boun...@ietf.org>]
on behalf of Rabadan, Jorge (Jorge)
[jorge.raba...@alcatel-lucent.com
<mailto:jorge.raba...@alcatel-lucent.com>]
*Sent:* Wednesday, November 11, 2015 0:01
*To:* Haoweiguo; saja...@cisco.com <mailto:saja...@cisco.com>;
jdr...@juniper.net <mailto:jdr...@juniper.net>
*Cc:* bess@ietf.org <mailto:bess@ietf.org>
*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 mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo
mailto:haowei...@huawei.com>>
*Date: *Tuesday, November 10, 2015 at 1:05 AM
*To: *"saja...@cisco.com <mailto:saja...@cisco.com>"
mailto:saja...@cisco.com>>,
"jdr...@juniper.net <mailto:jdr...@juniper.net>"
mailto:jdr...@juniper.net>>
*Cc: *"bess@ietf.org <mailto:bess@ietf.org>" mailto:bess@ietf.org>>
*Subject: *[bess] One question about 'draft-ietf-bess-evpn-overlay-02'
Hi A
Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
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 [jdr...@juniper.net] Sent: Wednesday, November 11, 2015 22:39 To: Haoweiguo; Rabadan, Jorge (Jorge); saja...@cisco.com Cc: bess@ietf.org 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:haowei...@huawei.com] Sent: Wednesday, November 11, 2015 1:08 AM To: Rabadan, Jorge (Jorge); saja...@cisco.com; John E Drake Cc: bess@ietf.org 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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com] Sent: Wednesday, November 11, 2015 11:47 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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 mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 7:03 PM To: Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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 [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>] Sent: Wednesday, November 11, 2015 0:01 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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 mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 1:05 AM To: "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr..
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:haowei...@huawei.com] Sent: Wednesday, November 11, 2015 1:08 AM To: Rabadan, Jorge (Jorge); saja...@cisco.com; John E Drake Cc: bess@ietf.org 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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com] Sent: Wednesday, November 11, 2015 11:47 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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 mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 7:03 PM To: Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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 [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>] Sent: Wednesday, November 11, 2015 0:01 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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 mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 1:05 AM To: "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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: 8VXLAN Encapsulation 9NVGRE 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com] Sent: Wednesday, November 11, 2015 11:47 To: Haoweiguo; saja...@cisco.com; jdr...@juniper.net Cc: bess@ietf.org 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 mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 7:03 PM To: Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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 [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>] Sent: Wednesday, November 11, 2015 0:01 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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 mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 1:05 AM To: "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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: 8VXLAN Encapsulation 9NVGRE 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
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 mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 7:03 PM To: Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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 [bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>] Sent: Wednesday, November 11, 2015 0:01 To: Haoweiguo; saja...@cisco.com<mailto:saja...@cisco.com>; jdr...@juniper.net<mailto:jdr...@juniper.net> Cc: bess@ietf.org<mailto:bess@ietf.org> 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 mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 1:05 AM To: "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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: 8VXLAN Encapsulation 9NVGRE 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
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 [bess-boun...@ietf.org] on behalf of Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com] Sent: Wednesday, November 11, 2015 0:01 To: Haoweiguo; saja...@cisco.com; jdr...@juniper.net Cc: bess@ietf.org 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 mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 1:05 AM To: "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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: 8VXLAN Encapsulation 9NVGRE 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
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 mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo mailto:haowei...@huawei.com>> Date: Tuesday, November 10, 2015 at 1:05 AM To: "saja...@cisco.com<mailto:saja...@cisco.com>" mailto:saja...@cisco.com>>, "jdr...@juniper.net<mailto:jdr...@juniper.net>" mailto:jdr...@juniper.net>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> 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: 8VXLAN Encapsulation 9NVGRE 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[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: 8VXLAN Encapsulation 9NVGRE 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
