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

[Thomas Morin <[e-mail]>]

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 and I think it is a serious 
breach of procedure to hold up the overlay draft by asserting you
 > know what the future portends.

Oh, oh, Big Words  :-D
(can you hear the faint murmur of lawyers in the background, impatient 
to enter the procedural battle ?)

Talking about "holding up" the draft could give the wrong impression 
that apart from this question, the draft is ready.
 From a strict procedural standpoint, if we set aside that it has been 
'expired' for 4 weeks, draft-ietf-bess-evpn-overlay is in the same state 
as draft-ietf-idr-tunnel-encaps, and noone knows its future for sure either.

And talking about "holding up" the draft could give the wrong impression 
on the kind of input I am providing, that merely relate to producing 
specs not only clear for its authors but to a larger audience. In that 
respect, if we can avoid a short term future where the draft would point 
to an obsolete spec, I think it will be better. Hence, having a 
normative reference to draft-ietf-idr-tunnel-encaps seems better.

IDR chairs and draft-ietf-idr-tunnel-encaps authors, do you know when we 
should expect a WGLC on draft-ietf-idr-tunnel-encaps ?
Progressing it quickly will help clarify all that.

If too far or too much unknown around the progress of 
draft-ietf-idr-tunnel-encaps, I can certainly live with 
draft-ietf-bess-evpn-overlay refer to RFC5512 normatively and to 
draft-ietf-idr-tunnel-encaps informatively, and have text explicitly 
state where things stand.  But's let's not rush, and remember that 
implementers care more about spec stability than knowing what the exact 
RFC number will be.

 > This is not the first time an RFC made a normative reference to an 
RFC that subsequently was obsoleted and the RFC system deals
 > quite nicely with this situation.

Of course we can deal with less-than-ideal... it doesn't mean we can't 
anticipate and do better.

-Thomas



> *From:*Thomas Morin [mailto:[e-mail]]
> *Sent:* Wednesday, May 18, 2016 10:23 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
>
> 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]>
>     [mailto:[e-mail]]
>     *Sent:* Wednesday, May 18, 2016 6:19 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
>
>     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
>         > >
>         > >
>