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

From: Thomas Morin <[email-masked]>
Date: Wed, 4 May 2016 14:57:39 +0200

Hi,

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.

* 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
* 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.

Thanks in advance,

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Wed, 4 May 2016 15:23:17 +0200

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 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.

This is really different than the approach used for other routes (not 
relying on the generic mechanism in draft-ietf-idr-tunnel-encaps), I 
think it would be worth highlighting, by adding something like:

    How the VNI or VSID is encoded in these route is done different
    from the approach used for other routes, because draft-ietf-idr-
    tunnel-encaps does not provide procedures describing how to derive a
    VNI or VSID from a Label in a PMSI Tunnel Attribute.

[ An alternative would be to have draft-ietf-idr-tunnel-encaps provide 
procedures describing how to derive a VNI or VSID from a Label in a PMSI 
Tunnel Attribute and have draft-ietf-bess-evpn-overlay follow that. I 
understand that the existence of implementation makes this hard to change. ]

-Thomas

2016-05-04, Thomas Morin:
>>     "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."
>

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Wed, 4 May 2016 18:06:12 +0000

Thomas,

Please see in-line.
Thank you.
Jorge

>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>

>> 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.

>> in section 5.1.3, and rather refer to draft-ietf-idr-tunnel-encaps instead

[JORGE] I agree.

>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: John E Drake <[email-masked]>
Date: Wed, 4 May 2016 18:34:11 +0000

Thomas and Jorge,

Snipped, comments inline.

Yours Irrespectively,

John

> [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.
> 

[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    

> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it would
> >> be better that draft-ietf-bess-evpn-overlay refers to
> [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 

> >>>     "If the BGP Encapsulation extended community is not present,
> >>> then the default MPLS encapsulation or a statically configured
> >>> to distinguish between an advertising node that only supports
> >>> non-MPLS encapsulations and one that supports MPLS and non-MPLS

[JD]  Fine with me either w/ or w/o the last sentence

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Wed, 4 May 2016 19:52:41 +0000

Hi John,

About this:

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

---

From: Ravi Shekhar <[email-masked]>
Date: Wed, 4 May 2016 20:45:50 +0000

Hi Jorge,
The VNI field in Ethernet Tag has been used to differentiate two BGP routes that have same MAC but different VNI/VLAN-ID. Ideally, it should not be used for nexthop creation. May be we can add that clarification.
Thanks.
- Ravi.

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Rabadan, Jorge (Nokia - US)
Sent: Wednesday, May 04, 2016 12:53 PM
To: John E Drake <[email-masked]>; EXT - [email-masked] <[email-masked]>; BESS <[email-masked]>; IDR <[email-masked]>; [email-masked]; Ali Sajassi (sajassi) <[email-masked]>
Subject: Re: [bess] [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 

Thanks.
Jorge

On 5/4/16, 8:34 PM, "EXT John E Drake" <[email-masked]> wrote:

>> >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.
>> 
>> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it 
>> >> would be better that draft-ietf-bess-evpn-overlay refers to 
>> [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]  According to IANA, it allocated the five tunnels types to the 
>overlay draft so I think we need to keep them
>
>
>> 
>> >>>     "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."
>> >>
>> >> skipping the last sentence would be wise if the full list of 
>> >> tunnel types is removed.
>
>
_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Wed, 4 May 2016 21:25:14 +0000

Hi Ravi,

Of course, in case of vlan-aware bundle services. But should be zero in case of VLAN-based or VLAN-bundle.
Thx
Jorge

---

From: John E Drake <[email-masked]>
Date: Wed, 4 May 2016 21:34:38 +0000

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

> From: Rabadan, Jorge (Nokia - US) [mailto:[email-masked]]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - [email-masked]; BESS; IDR; draft-ietf-bess-evpn-
> [email-masked]; 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.
> 
> 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
> 
> 
> 
> 
>

---

From: Ravi Shekhar <[email-masked]>
Date: Wed, 4 May 2016 21:39:09 +0000

Hi Jorge, As per the current spec that is correct - it is being used only for vlan-aware bundle model.

For vlan-based, if a system supports more than 64K vlans, keeping Etag zero forces implementation to create new RDs. The current IP address based RD structure only has 16 bits left in RD for identifying vlans. If RD has to be auto-derived, it also adds extra complexity in the implementation that it has to now manage a separate 16 bit number space (across graceful restart, and across configured RDs). It would be much easier if one could use configured 24 bits of vnid/vlan-id to do that. Ideally, we should give it a structure like auto-RT : 1 bit for auto/manual and 24 bits for vlan identification, and put those 32 bits to good use even for vlan-based.

Alternative is to define a new type of RD that leaves 3 bytes of RD available to fit in vlan identification. The current types of RD are only a handful, but the type field takes a full 2 byte space. We can possibly free up a byte from that space. Since the problem is very specific to EVPN, I am not sure if it is prudent to do that. Using 32 bits of Ethernet tag in EVPN routes sounds more appropriate for this purpose.

Thanks.
- Ravi.

-----Original Message-----
From: Rabadan, Jorge (Nokia - US) [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2016 2:25 PM
To: Ravi Shekhar <[email-masked]>; John E Drake <[email-masked]>; EXT - [email-masked] <[email-masked]>; BESS <[email-masked]>; IDR <[email-masked]>; [email-masked]; Ali Sajassi (sajassi) <[email-masked]>
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi Ravi,

On 5/4/16, 10:45 PM, "EXT Ravi Shekhar" <[email-masked]> wrote:

>To: John E Drake <[email-masked]>; EXT - [email-masked] 
><[email-masked]>; BESS <[email-masked]>; IDR <[email-masked]>; 
>[email-masked]; Ali Sajassi (sajassi) 
><[email-masked]>
>[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
>
>
>>> >>> 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.
>>
>>

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Wed, 4 May 2016 21:41:19 +0000

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-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
To: IDR <[email-masked]<mailto:[email-masked]>>, Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>>, Rabadan, Jorge (Nokia - US) <[email-masked]<mailto:[email-masked]>>, BESS <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Jorge,

Yours Irrespectively,

John

> To: John E Drake; EXT - [email-masked]<mailto:[email-masked]>; BESS; IDR; draft-ietf-bess-evpn-
> [email-masked]<mailto:[email-masked]>; Ali Sajassi (sajassi)
> On 5/4/16, 8:34 PM, "EXT John E Drake" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >Thomas and Jorge,
> >

---

From: <[email-masked]>
Date: Thu, 5 May 2016 12:31:53 +0000

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 ----

Thanks,
Jorge

Jorge,

Yours Irrespectively,

John

> >[JD] Fine with me either w/ or w/o the last sentence

_________________________________________________________________________________________________________________________

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.

---

From: John E Drake <[email-masked]>
Date: Thu, 5 May 2016 12:57:05 +0000

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-masked] [mailto:[email-masked]]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; [email-masked]; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); [email-masked]
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

> In case it helps, I've seen a few implementations running and they all encode the VNI in the

Thank you.

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Thu, 5 May 2016 13:45:27 +0000

I agree with John.

Thanks.
Jorge

On 5/5/16, 2:57 PM, "EXT John E Drake" <[email-masked]<mailto:[email-masked]>> wrote:

Thomas,

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; [email-masked]<mailto:[email-masked]>; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

Thank you.

---

From: <[email-masked]>
Date: Thu, 5 May 2016 21:47:14 +0000

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?

-Thomas

---- John E Drake a écrit ----

Thomas,

Yours Irrespectively,

John

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

Thank you.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 5 May 2016 22:13:04 +0000

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-assigned VNI in MPLS field (in EVPN routes versus PTA) for unicast packets versus BUM packets.

Is there any other things that need to be clarified?

BTW, thanks for doing a thorough review of the doc.

Cheers,
Ali

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 5, 2016 at 2:47 PM
To: IDR <[email-masked]<mailto:[email-masked]>>, BESS <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi John,

-Thomas

---- John E Drake a écrit ----

Thomas,

Yours Irrespectively,

John

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

Thank you.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 5 May 2016 22:22:35 +0000

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 solution from the beginning never needed and rely such attribute - i.e., EVPN precedes the tunnel attribute definition.

Cheers,
Ali

From: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 5, 2016 at 3:13 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IDR <[email-masked]<mailto:[email-masked]>>, BESS <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi Thomas,

Cheers,
Ali

Hi John,

-Thomas

---- John E Drake a écrit ----

Thomas,

Yours Irrespectively,

John

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; [email-masked]<mailto:[email-masked]>; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 5 May 2016 22:38:52 +0000

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 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.

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.

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-masked] [mailto:[email-masked]]
Sent: Thursday, May 05, 2016 5:47 PM
To: IDR; BESS; [email-masked]; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); [email-masked]; John E Drake
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi John,

-Thomas

---- John E Drake a écrit ----
Thomas,

Yours Irrespectively,

John

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 18 May 2016 12:18:55 +0200

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-masked] [mailto:[email-masked]]
> *Sent:* Thursday, May 05, 2016 5:47 PM
> *To:* IDR; BESS; [email-masked]; Ali 
> Sajassi (sajassi); Rabadan, Jorge (Nokia - US); 
> [email-masked]; 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.
>
> 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-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *Sent:* Thursday, May 05, 2016 8:32 AM
> *To:* John E Drake; IDR; BESS; 
> [email-masked] 
> <mailto:[email-masked]>; Ali Sajassi 
> (sajassi); Rabadan, Jorge (Nokia - US); 
> [email-masked] 
> <mailto:[email-masked]>
> *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.
>
> From: EXT John E Drake <[email-masked] <mailto:[email-masked]>>
> To: IDR <[email-masked] <mailto:[email-masked]>>, Ali Sajassi (sajassi) 
> <[email-masked] <mailto:[email-masked]>>, Rabadan, Jorge (Nokia 
> - US) <[email-masked] 
> <mailto:[email-masked]>>, BESS <[email-masked] 
> <mailto:[email-masked]>>, <[email-masked] 
> <mailto:[email-masked]>>, EXT - 
> [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]>>
>
>
> 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).
>
> > To: John E Drake; EXT - [email-masked] 
> <mailto:[email-masked]>; BESS; IDR; draft-ietf-bess-evpn-
> > [email-masked] <mailto:[email-masked]>; Ali Sajassi 
> (sajassi)
> attribute. I think we need
> attribute. I think we
> > need to ask everyone whether they

---

From: John E Drake <[email-masked]>
Date: Wed, 18 May 2016 14:15:50 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 18, 2016 6:19 AM
To: John E Drake; IDR; BESS; [email-masked]; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); [email-masked]
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi John,

John.

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

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-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, May 05, 2016 5:47 PM
To: IDR; BESS; [email-masked]<mailto:[email-masked]>; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); [email-masked]<mailto:[email-masked]>; 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.

-Thomas

---- John E Drake a écrit ----
Thomas,

Yours Irrespectively,

John

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

Thank you.

---

From: Thomas Morin <[email-masked]>
Date: Wed, 18 May 2016 16:22:59 +0200

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

> *Sent:* Wednesday, May 18, 2016 6:19 AM
> [email-masked]; Ali Sajassi (sajassi); 
> Rabadan, Jorge (Nokia - US); [email-masked]
> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. 
>     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.
>
>
>     forward the extended community and to obsolete RFC 5512, so we
>     were effectively covered by a grandfather clause.
>
>
>     Given the overlay draft’s tardiness, I don’t think that’s
>     acceptable and would prefer to continue to refer to RFC 5512.
>
>
> If it helps, the draft can keep an informative ref to RFC5512 and 
> remind that it does not rely on anything specifically introduced by 
>     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
>
>     *To:* IDR; BESS; [email-masked]
>     <mailto:[email-masked]>; John E Drake
>     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.
>
>     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.
>
>     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
>
>     draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some
>     tidying up.
>
>     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.
>
>     Fully agree John. That's what I meant, sorry if I didn't make
>     myself clear. Section 9 needs clean up, yes.
>
>     Thanks,
>     Jorge
>
>     To: IDR <[email-masked] <mailto:[email-masked]>>, Ali Sajassi
>     (sajassi) <[email-masked] <mailto:[email-masked]>>, Rabadan,
>     Jorge (Nokia - US) <[email-masked]
>     <mailto:[email-masked]>>,
>     <[email-masked]
>     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
>     > [email-masked] <mailto:[email-masked]>; Ali
>     Sajassi (sajassi)
>     > >[JD] For the IMET route the MPLS label field is carried in the
>     PMSI attribute. I think we
>     supports
>     although

---

From: John E Drake <[email-masked]>
Date: Wed, 18 May 2016 18:54:54 +0000

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 what the future portends.

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.

Yours Irrespectively,

John

From: Thomas Morin [mailto:[email-masked]]
Sent: Wednesday, May 18, 2016 10:23 AM
To: John E Drake; IDR; BESS; [email-masked]; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); [email-masked]
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.

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

Hi John,

John.

-Thomas

Yours Irrespectively,

John

Hi John,

-Thomas

---- John E Drake a écrit ----
Thomas,

Yours Irrespectively,

John

-Thomas

---- Rabadan, Jorge (Nokia - US) a écrit ----

Jorge,

Yours Irrespectively,

John

---

From: Thomas Morin <[email-masked]>
Date: Thu, 19 May 2016 10:34:15 +0200

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:[email-masked]]
> *Sent:* Wednesday, May 18, 2016 10:23 AM
>     I spoke with Ali and he will reference the tunnel encapsulation
>     draft rather than RFC 5512 but make it Informative.
>
> draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not 
> the reverse.
>         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.
>
>
>
>         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.
>
>
>     remind that it does not rely on anything specifically introduced
>     by draft-ietf-idr-tunnel-encaps and not existing already in RFC5512.
>
>     -Thomas
>
>
>         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.
>
>         *From:[email-masked]
>         <mailto:[email-masked]> [mailto:[email-masked]]
>         <mailto:[email-masked]>; Ali
>         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.
>
>         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-masked]
>         <mailto:[email-masked]> [mailto:[email-masked]]
>         <mailto:[email-masked]>; Ali
>         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.
>
>         (sajassi) <[email-masked] <mailto:[email-masked]>>,
>         Rabadan, Jorge (Nokia - US) <[email-masked]
>         <mailto:[email-masked]>>, BESS
>         <[email-masked] <mailto:[email-masked]>>,
>         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
>         > >[JD] For the IMET route the MPLS label field is carried in
>         the PMSI attribute. I think we

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 24 May 2016 07:04:53 +0000

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. Section 5.1.3 captures the setting of these fields for different type of services in pretty good details. All other sections were cleaned up and now refer to section 5.1.3.

Thomas,
The draft is ready for its long-overdue WG LC considering how long its has been around and its multi-vendor implementation status.

Regards,
Ali

---

From: John E Drake <[email-masked]>
Date: Tue, 24 May 2016 13:39:26 +0000

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 like to request that Jorge be the document shepherd for this draft.

Yours Irrespectively,

John

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, May 24, 2016 3:05 AM
To: John E Drake; EXT - [email-masked]; IDR; BESS; [email-masked]; Rabadan, Jorge (Nokia - US); [email-masked]
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Folks,

The main changes are:

Thomas,

Regards,
Ali