*From:*Thomas Morin [mailto:[email protected]]
*Sent:* Wednesday, May 18, 2016 10:23 AM
*To:* John E Drake; IDR; BESS;
[email protected]; Ali Sajassi (sajassi);
Rabadan, Jorge (Nokia - US); [email protected]
*Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps
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 we should do is normatively refer to
draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not
the reverse.
Or else we end up with an RFC that soon after publication will
normatively depend to an obsoleted RFC.
-Thomas
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected]]
*Sent:* Wednesday, May 18, 2016 6:19 AM
*To:* John E Drake; IDR; BESS;
[email protected]
<mailto:[email protected]>; Ali Sajassi
(sajassi); Rabadan, Jorge (Nokia - US);
[email protected]
<mailto:[email protected]>
*Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps
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 decided to continue to use the
extended community. So, in that sense we are misaligned with
the tunnel encaps draft.
As you confirm below, the last sentence is only true in the past
tense.
Subsequently, however, the tunnel encaps draft decided to
carry forward the extended community and to obsolete RFC 5512,
so we were effectively covered by a grandfather clause.
Yes, precisely: given the content of the two drafts, there is no
misalignment anymore.
Given the overlay draft’s tardiness, I don’t think that’s
acceptable and would prefer to continue to refer to RFC 5512.
I do not think that the additional publication delay is a sound
rationale for normatively refer to a spec that is known to become
obsolete.
If it helps, the draft can keep an informative ref to RFC5512 and
remind that it does not rely on anything specifically introduced
by draft-ietf-idr-tunnel-encaps and not existing already in RFC5512.
-Thomas
2016-05-06, John E Drake:
However, even though I agreed yesterday to refer to the tunnel
encaps draft instead of RFC 5512 we have an issue with doing
this, viz, the overlay draft makes a normative reference to
RFC 5512. If we change the normative reference to the tunnel
encaps draft we cannot publish the overlay draft until after
the tunnel encaps draft has been published.
Given the overlay draft’s tardiness, I don’t think that’s
acceptable and would prefer to continue to refer to RFC 5512.
Yours Irrespectively,
John
*From:*[email protected]
<mailto:[email protected]> [mailto:[email protected]]
*Sent:* Thursday, May 05, 2016 5:47 PM
*To:* IDR; BESS; [email protected]
<mailto:[email protected]>; Ali
Sajassi (sajassi); Rabadan, Jorge (Nokia - US);
[email protected]
<mailto:[email protected]>; John E Drake
*Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps
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 (below) the two docs "not aligned" for unicast.
Can you be more explicit in where the "misalignment" lies?
-Thomas
---- John E Drake a écrit ----
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 problem and the
WG decided a long time ago that the overlay draft was not
going to be updated to use the mechanisms it details for
unicast, so the overlay draft is already explicitly not in
alignment with it.
This, plus the fact that the tunnel encaps draft explicitly
puts the PMSI out of scope, leads me to the conclusion that
the overlay draft should not be tweaked to be in alignment
with a future solution for encoding VNIs for multicast.
Yours Irrespectively,
John
*From:*[email protected]
<mailto:[email protected]> [mailto:[email protected]]
*Sent:* Thursday, May 05, 2016 8:32 AM
*To:* John E Drake; IDR; BESS;
[email protected]
<mailto:[email protected]>; Ali
Sajassi (sajassi); Rabadan, Jorge (Nokia - US);
[email protected]
<mailto:[email protected]>
*Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps
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 to what is done
for unicast.
It seems if course that draft-ietf-idr-tunnel-encap should be
the place, but that document currently explicitly makes PMSIs
out of scope.
Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?
-Thomas
---- Rabadan, Jorge (Nokia - US) a écrit ----
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 <[email protected]
<mailto:[email protected]>>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps
To: IDR <[email protected] <mailto:[email protected]>>, Ali Sajassi
(sajassi) <[email protected] <mailto:[email protected]>>,
Rabadan, Jorge (Nokia - US) <[email protected]
<mailto:[email protected]>>, BESS
<[email protected] <mailto:[email protected]>>,
<[email protected]
<mailto:[email protected]>>, EXT -
[email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]>>
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 right that we need to clean up section 9.
Yours Irrespectively,
John
> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US)
[mailto:[email protected]]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - [email protected]
<mailto:[email protected]>; BESS; IDR; draft-ietf-bess-evpn-
> [email protected] <mailto:[email protected]>; Ali
Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps
>
> 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 in the
> MPLS label field in the PTA. And a couple of them, encode
the VNI in the ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think
section 9 contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD
per EVI, and **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or
VSID."
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <[email protected]
<mailto:[email protected]>> wrote:
>
> >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 the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version
where the
> >> VNI/VSID was encoded in the ethernet tag for all the
routes. The VNI
> >> should be encoded in the Label field in all the routes.
This has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned
VNIs, the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per
EVI, and
> >> Inclusive Multicast Ethernet Tag routes is used to carry
the VNI or
> >> VSID. For the balance of this memo, the MPLS label field
will be
> >> referred to as the VNI/VSID field. The VNI/VSID field is
used for
> >> both local and global VNIs/VSIDs, and for either case the
entire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[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
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with
> >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate
RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay
refers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps
keeps the
> >> encapsulation extended community. There are a few
implementations
> >> using this community and it is enough when only the
encapsulation type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit
list of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types
to the
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but
not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> 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."
> >> >>
> >> >> I think this change is useful and should be
incorporated, although
> >> >> skipping the last sentence would be wise if the full
list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >
