Thomas,
Please see in-line.
Thank you.
Jorge
On 5/4/16, 3:23 PM, "Idr on behalf of EXT Thomas Morin" wrote:
>Hi,
>
>There is another point that I missed in this first email.
>
>draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
>Encapsulation extended to encode the tunnel encap
Thomas and Jorge,
Snipped, comments inline.
Yours Irrespectively,
John
> >
> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
> >Encapsulation extended to encode the tunnel encap to use for BUM
> >traffic, but contrary to other E-VPN routes, relies on the Ethernet Tag
> >field of
Hi John,
About this:
[JD] For the IMET route the MPLS label field is carried in the PMSI attribute.
I think we need to ask everyone whether they
used the Ethernet Tag or the PMSI attribute to carry the VNI
In case it helps, I’ve seen a few implementations running and they all encode
the VNI
...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia -
US)
Sent: Wednesday, May 04, 2016 12:53 PM
To: John E Drake ; EXT - thomas.mo...@orange.com
; BESS ; IDR ;
draft-ietf-bess-evpn-over...@tools.ietf.org; Ali Sajassi (sajassi)
Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf
: Wednesday, May 04, 2016 12:53 PM
>To: John E Drake ; EXT - thomas.mo...@orange.com
>; BESS ; IDR ;
>draft-ietf-bess-evpn-over...@tools.ietf.org; Ali Sajassi (sajassi)
>
>Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs.
>draft-ietf-idr-tunnel-encaps
>
>Hi J
Jorge,
We put the VNI value in the MPLS label field of the PMSI attribute for all
service types, and we put a value in the Ethernet Tag field following the rules
for each service type as described in 5.1.3
(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).
You're righ
[mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge
>(Nokia - US)
>Sent: Wednesday, May 04, 2016 12:53 PM
>To: John E Drake ; EXT - thomas.mo...@orange.com
>; BESS ; IDR ;
>draft-ietf-bess-evpn-over...@tools.ietf.org; Ali Sajassi (sajassi)
>
>Subject: Re: [bess] [
Fully agree John. That's what I meant, sorry if I didn't make myself clear.
Section 9 needs clean up, yes.
Thanks,
Jorge
_
From: EXT John E Drake mailto:jdr...@juniper.net>>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-i
Thanks for the clarification on the intent around draft-ietf-bess-evpn-overlay.
Then indeed section 9 needs some tidying up.
The issue that I think remain is that it would be much cleaner to explain how
to use PMSI with overlay encaps in a spec not specific to E-VPN and in a way
more consistent
Thomas,
The overlay draft preceded the tunnel encaps draft and it was designed to
handle a very specific problem, marrying the EVPN control plane to the VXLAN
data plane draft and modulo the correction to section 9 it is internally
consistent.
The tunnel encaps draft solves a more general prob
I agree with John.
Thanks.
Jorge
On 5/5/16, 2:57 PM, "EXT John E Drake"
mailto:jdr...@juniper.net>> wrote:
Thomas,
The overlay draft preceded the tunnel encaps draft and it was designed to
handle a very specific problem, marrying the EVPN control plane to the VXLAN
data plane draft and modul
Hi John,
I have a hard time reconciliating the fact that yesterday you were fine with
having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, with the
fact that you consider (belox) the two docs "not aligned" for unicast.
Can you be more explicit in where the "misalignment" lies?
Hi Thomas,
With respect to tunnel type extended community used in evpn-overlay, we can
refer to idr-tunnel-encap instead of RFC5512. However, besides that I don’t see
any other point of contention that needs resolving.
We agreed that there needs to be some clarification with respect
locally-a
Hi Thomas,
One other thing regarding your earlier question. In EVPN, we decided long time
ago that we’ll use tunnel type extended community but not the attribute. So,
maybe that’s the “mis-alignement” that John was talking about but that should
not be considered as mis-alignment since EVPN sol
Thomas,
My apologies, I mis-stated the sequence of events.
When the tunnel encaps draft was first published it did not carry forward the
RFC 5512 extended community and it did not propose to obsolete RFC 5512. There
was discussion of using the attribute defined in the tunnel encaps draft
inst
Hi John,
John.
When the tunnel encaps draft was first published it did not carry
forward the RFC 5512 extended community and it did not propose to
obsolete RFC 5512. There was discussion of using the attribute
defined in the tunnel encaps draft instead of the extended community
and we decide
Thomas,
I spoke with Ali and he will reference the tunnel encapsulation draft rather
than RFC 5512 but make it Informative. I think this is in the spirit of what
you proposed in your email, below.
Yours Irrespectively,
John
From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
Sent:
John,
2016-05-18, John E Drake:
I spoke with Ali and he will reference the tunnel encapsulation draft
rather than RFC 5512 but make it Informative.
I think this is in the spirit of what you proposed in your email, below.
Well, only for some definition of "in the spirit"... :-/
What I think w
Thomas,
I disagree.
Unless and until Eric’s draft is published the normative reference is to RFC
5512 and neither you nor anyone else knows when or if Eric’s draft will be
published as an RFC and I think it is a serious breach of procedure to hold up
the overlay draft by asserting you know wha
Hi John,
[with a question to IDR chairs and draft-ietf-idr-tunnel-encaps authors
below]
2016-05-18, John E Drake:
> Unless and until Eric’s draft is published the normative reference is
to RFC 5512 and neither you nor anyone else knows when or if
> Eric’s draft will be published as an RFC an
Folks,
I have updated and published rev03 of even-overlay draft.
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/
The main changes are:
1. section 10.2 - DCI using ASBR
2. The setting of Ethernet tag and VNI fields - there were some
inconsistencies in different sections. Se
Hi,
Ali and I decided to keep the normative reference to RFC 5512 rather than
changing it to Eric's tunnel encapsulation draft because the normative
reference pre-dates Eric's draft and because our draft does not use any of the
new capabilities introduced in Eric's draft.
Ali and I would also
Hi Thomas,
I updated and checked-in a new rev of this draft couple of weeks ago to address
the comments that came up on this email thread - the main changes were outlined
in my previous email. Can you please progress this draft for its LC. If there
is any issue preventing the progress of this
Hi,
We are fine with keeping 5512 as the Normative reference for now.
We would think it wise if the editors can add an Informative reference
to draft-ietf-idr-tunnel-encaps (with some text indicating that both
specs provide the required support for the procedures).
The ideal situation would be
Hi Martin,
We¹ll also add idr-tunnel-encaps a Informative reference. With respect to
Tunnel Encap Extended Community (which is the only part of
idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself
references RFC 5512.
During the course of WG LC and RFC editorship of evpn-ov
t: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs.
> draft-ietf-idr-tunnel-encaps
>
>
> Hi Martin,
>
> We¹ll also add idr-tunnel-encaps a Informative reference. With respect to
> Tunnel Encap
> Extended Community (which is the only part of idr-tunnel-encap used by
>
Thank you Ali
Le 07/06/2016 18:04, Ali Sajassi (sajassi) a écrit :
Hi Martin,
We¹ll also add idr-tunnel-encaps a Informative reference. With respect to
Tunnel Encap Extended Community (which is the only part of
idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself
referenc
Hi Ali,
The changes in -04 look good.
I would have one suggestion: say explicitly that the "use the label as
the VNI" behavior is the same as what the tunnel encap says.
This could be done by adding something like the following to section
5.1.3 :
Note that the procedure defined here to u
ess@ietf.org
> Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs.
> draft-ietf-idr-tunnel-encaps
>
> Hi Ali,
>
> The changes in -04 look good.
>
> I would have one suggestion: say explicitly that the "use the label as the
> VNI" behavior is
> the sa
Hi Thomas,
Referencing the section 8 of idr-tunnel-encap draft is too wide a scope
IMHO and maybe confusing, thus I'd like to narrow it down. I went over the
both sections 3.5 and 8 of the idr-tunnel-encap draft and with respect to
your comment, I’d like to narrow it to only section 8.2.2.2. ("Wh
Sounds perfect.
Thanks,
-Thomas
Ali Sajassi (sajassi) a écrit
Hi Thomas,
Referencing the section 8 of idr-tunnel-encap draft is too wide a scope
IMHO and maybe confusing, thus I'd like to narrow it down. I went over the
both sections 3.5 and 8 of the idr-tunnel-encap draft and with
31 matches
Mail list logo
