Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

[Thomas Morin <[e-mail]>]

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:*[e-mail] [mailto:[e-mail]]
> *Sent:* Wednesday, May 18, 2016 6:19 AM
> *To:* John E Drake; IDR; BESS; 
> [e-mail]; Ali Sajassi (sajassi); 
> Rabadan, Jorge (Nokia - US); [e-mail]
> *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:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]]
>     *Sent:* Thursday, May 05, 2016 5:47 PM
>     *To:* IDR; BESS; [e-mail]
>     <mailto:[e-mail]>; Ali Sajassi
>     (sajassi); Rabadan, Jorge (Nokia - US);
>     [e-mail]
>     <mailto:[e-mail]>; 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:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]]
>     *Sent:* Thursday, May 05, 2016 8:32 AM
>     *To:* John E Drake; IDR; BESS;
>     [e-mail]
>     <mailto:[e-mail]>; Ali Sajassi
>     (sajassi); Rabadan, Jorge (Nokia - US);
>     [e-mail]
>     <mailto:[e-mail]>
>     *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 <[e-mail]
>     <mailto:[e-mail]>>
>     Sent: Wednesday, May 4, 2016 23:34
>     Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs.
>     draft-ietf-idr-tunnel-encaps
>     To: IDR <[e-mail] <mailto:[e-mail]>>, Ali Sajassi
>     (sajassi) <[e-mail] <mailto:[e-mail]>>, Rabadan,
>     Jorge (Nokia - US) <[e-mail]
>     <mailto:[e-mail]>>, BESS <[e-mail]
>     <mailto:[e-mail]>>,
>     <[e-mail]
>     <mailto:[e-mail]>>, EXT -
>     [e-mail] <mailto:[e-mail]>
>     <[e-mail] <mailto:[e-mail]>>
>
>
>     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:[e-mail]]
>     > Sent: Wednesday, May 04, 2016 3:53 PM
>     > To: John E Drake; EXT - [e-mail]
>     <mailto:[e-mail]>; BESS; IDR; draft-ietf-bess-evpn-
>     > [e-mail] <mailto:[e-mail]>; 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" <[e-mail]
>     <mailto:[e-mail]>> 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
>     > >
>     > >
>