Subject: [bess] EVPN Draft Comments

From: "Russ White" <[email-masked]>
Date: Mon, 2 Feb 2015 08:42:02 -0500

Y'all:

I know this is in auth-48 (or maybe past), but I've been through these docs
a number of times, and still come up with questions that I think need to be
addressed/answered at some point. In general, eVPN seems to be on the
receiving end of "I can imagine a lot of different use cases, some of which
are self-contradictory, but let's just throw it all in the bucket anyway,
regardless of the complexity and other problems." But, aside from that --
some specific comments on the base draft --

==
Section 7.2

The MAC address field in the TLV is specified as 6 octets, but there is also
a MAC address length field -- normally you would only include a length field
if the field itself is variable length, which doesn't appear to be the case
here. Is there some specific reason a length field is included, and the
length of the field is specified?

==
Section 7.6

This is a new transitive Route Target extended community carried with
the Ethernet Segment route. When used, it enables all the PEs
connected to the same multi-homed site to import the Ethernet Segment
routes. The value is derived automatically from the ESI by encoding
the high order 6-octet portion of the 9-octet ESI Value in the ESImport
Route Target. The high order 6-octet of the ESI incorporates
MAC address of ESI (for type 1, 2, and 3) which when encoded in this
RT and used in the RT constrain feature, it enables proper routetarget
filtering. The format of this extended community is as
follows:

However, the high order 6 octet portion of the ESI is not unique -- the
section on forming the ESI actually includes instructions that would mean
multiple ESIs with the same higher order 6 octet. When we're dealing with
MAC addresses and overlapping IP address sets, it will be problematic to
install destinations from one ESI into the MAC-VRF in another ESI.

This is related to section 8.1.1, as well, which deals with route filtering.

==
8.2.1

Throughout most of the document, the ESI is described as being 9 octets.
Here it is described as being 10 octets. No explanation is given.

==
8.4

The entire concept of aliasing appears dangerous to me. It would have been
better to separate the MAC address from the EVI in two separate
advertisements, making reachability to the MAC address in reference to the
EVI, and reachabality to the EVI it's "own thing," rather than tying the two
together and then creating an "alias." 

==
8.5

The definition of "service carving" is buried in the text in the middle of
section 8.5. Shouldn't this be included in the glossary, at least?

==
8.5

In step 3 of DF election, the list of IP addresses is ordered in "increasing
numeric value." What if you have a mix of v4 and v6 addresses?

==

:-)

Russ

---

From: John E Drake <[email-masked]>
Date: Mon, 2 Feb 2015 13:46:59 +0000

Russ,

I am under the impression that Adrian's email asked for comments on the proposed change to section 6.3. 

Yours Irrespectively,

John

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Monday, February 02, 2015 8:42 AM
> To: [email-masked]
> Subject: [bess] EVPN Draft Comments
> 
> Y'all:
> 
> I know this is in auth-48 (or maybe past), but I've been through these docs a
> number of times, and still come up with questions that I think need to be
> receiving end of "I can imagine a lot of different use cases, some of which are
> self-contradictory, but let's just throw it all in the bucket anyway, regardless
> of the complexity and other problems." But, aside from that -- some specific
> comments on the base draft --
> 
> ==
> Section 7.2
> 
> The MAC address field in the TLV is specified as 6 octets, but there is also a
> MAC address length field -- normally you would only include a length field if
> the field itself is variable length, which doesn't appear to be the case here. Is
> there some specific reason a length field is included, and the length of the
> field is specified?
> 
> ==
> Section 7.6
> 
> This is a new transitive Route Target extended community carried with the
> Ethernet Segment route. When used, it enables all the PEs connected to the
> same multi-homed site to import the Ethernet Segment routes. The value is
> derived automatically from the ESI by encoding the high order 6-octet
> portion of the 9-octet ESI Value in the ESImport Route Target. The high order
> 6-octet of the ESI incorporates MAC address of ESI (for type 1, 2, and 3)
> which when encoded in this RT and used in the RT constrain feature, it
> enables proper routetarget filtering. The format of this extended community
> is as
> follows:
> 
> However, the high order 6 octet portion of the ESI is not unique -- the section
> on forming the ESI actually includes instructions that would mean multiple
> ESIs with the same higher order 6 octet. When we're dealing with MAC
> addresses and overlapping IP address sets, it will be problematic to install
> destinations from one ESI into the MAC-VRF in another ESI.
> 
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Feb 2015 08:58:31 -0500

John --

> proposed change to section 6.3.

This isn't in response to Adrian's email. This is a long stewing email that
I've finally gotten around to sending, after spending many hours trying to
make certain I'm not bringing up things that are covered someplace else.
Again, these might not need to be addressed in this particular version of
the draft, but there are some things here that might need to be cleared up
in a future bis version, or at least explained, in some way, as they are
errors in the draft, and may actually impact the operation of any given
implementation. I'm assuming we'll end up with bis versions, given the state
of the drafts as we move into this final phase of publication.

:-)

Russ

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Mon, 2 Feb 2015 15:39:19 +0000

Hi Russ,

Since we are I think in agreement this must NOT hold the process, I give
you my 2 cents if I may...

Section 7.2 - the mac length field is fixed in EVPN to 48, but it has to
be there to allow future use-cases. For instance, it might make sense to
use variable mac lengths in PBB-EVPN since the BMACs are operator-managed.

Section 7.6 - this is not an issue to me. The ESI has to be unique in the
network. The mechanisms to auto-derive the ESI can only be used if they
guarantee the uniqueness of the ESI. And since the ES-import route-target
is a route-target, its value can only be present on the PEs where you want
to import the route. I don’t think there is a need for clarification of
the text.

Also, I think aliasing is a great thing to support.

Thanks.
Jorge

---

From: Russ White <[email-masked]>
Date: Mon, 2 Feb 2015 15:02:20 -0500

If the length of the layer 2 address is fixed, there is no way to accommodate future use cases regardless of the inclusion of a length field. The way the draft is written, it would be justifiable to ignore the length field, destroying future expansion. Adding a length field to a fixed length filed doesn't mean the length of the fixed length field can change -- otherwise it wouldn't be fixed length.

The aliasing procedure, to me,says "we didn't think through these relationships well, so let's throw in a way to get around the limitations we put into the original draft." This isn't an elegant solution.

If the esi must be unique, and it's important, then the esi must be unique as used. Using a non-unique part of the esi destroys the point of building a unique esi in the first place.

Two of these are going to be problems in real world deployments, and need, imho, to be fixed in a bis.

:-)

Russ

> On Feb 2, 2015, at 10:39 AM, Rabadan, Jorge (Jorge) <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: John E Drake <[email-masked]>
Date: Mon, 2 Feb 2015 20:41:02 +0000

Russ,

Comments inline.    

Yours Irrespectively,

John

> Sent: Monday, February 02, 2015 3:02 PM
> To: Rabadan, Jorge (Jorge)
> Cc: [email-masked]
> Subject: Re: [bess] EVPN Draft Comments
> 
> 
> If the length of the layer 2 address is fixed, there is no way to accommodate
> future use cases regardless of the inclusion of a length field. The way the
> draft is written, it would be justifiable to ignore the length field, destroying
> future expansion. Adding a length field to a fixed length filed doesn't mean
> the length of the fixed length field can change -- otherwise it wouldn't be
> fixed length.

[JD]  What RFC 7432 actually says is:  "The MAC Address Length field is in bits, and it is set to 48.
MAC address length values other than 48 bits are outside the scope of this document."  So,
The MAC Address field is a variable length field whose length is currently set to 48.  

> 
> The aliasing procedure, to me,says "we didn't think through these
> relationships well, so let's throw in a way to get around the limitations we put
> into the original draft." This isn't an elegant solution.

[JD]  Just because you don't like/understand it doesn't necessarily mean it's wrong.    

> 
> If the esi must be unique, and it's important, then the esi must be unique as
> used. Using a non-unique part of the esi destroys the point of building a
> unique esi in the first place.

[JD]  The ESI is unique.  The ES-Import RT is not.  This means that some PEs may import an Ethernet Segment route
that are not attached to the ES specified in the Ethernet Segment route.  When they examine the Ethernet Segment
route they will realize this and discard it.

> > On Feb 2, 2015, at 10:39 AM, Rabadan, Jorge (Jorge)
> <[email-masked]> wrote:
> >
> > Hi Russ,
> >
> > Since we are I think in agreement this must NOT hold the process, I
> > give you my 2 cents if I may...
> >
> > Section 7.2 - the mac length field is fixed in EVPN to 48, but it has
> > to be there to allow future use-cases. For instance, it might make
> > sense to use variable mac lengths in PBB-EVPN since the BMACs are
> operator-managed.
> >
> >
> > Section 7.6 - this is not an issue to me. The ESI has to be unique in
> > the network. The mechanisms to auto-derive the ESI can only be used if
> > they guarantee the uniqueness of the ESI. And since the ES-import
> > route-target is a route-target, its value can only be present on the
> > PEs where you want to import the route. I don’t think there is a need
> > for clarification of the text.
> >
> >> I know this is in auth-48 (or maybe past), but I've been through
> >> these docs a number of times, and still come up with questions that I
> >> think need to be addressed/answered at some point. In general, eVPN
> >> seems to be on the receiving end of "I can imagine a lot of different
> >> use cases, some of which are self-contradictory, but let's just throw
> >> it all in the bucket anyway, regardless of the complexity and other
> >> problems." But, aside from that -- some specific comments on the base
> >> draft --
> >>
> >> ==
> >> Section 7.2
> >>
> >> The MAC address field in the TLV is specified as 6 octets, but there
> >> is also a MAC address length field -- normally you would only include
> >> a length field if the field itself is variable length, which doesn't
> >> appear to be the case here. Is there some specific reason a length
> >> field is included, and the length of the field is specified?
> >>
> >> ==
> >> Section 7.6
> >>
> >> the high order 6-octet portion of the 9-octet ESI Value in the
> >> ESImport Route Target. The high order 6-octet of the ESI incorporates
> >> RT and used in the RT constrain feature, it enables proper
> >> routetarget filtering. The format of this extended community is as
> >> follows:
> >>
> >> However, the high order 6 octet portion of the ESI is not unique --
> >> the section on forming the ESI actually includes instructions that
> >> would mean multiple ESIs with the same higher order 6 octet. When
> >> we're dealing with MAC addresses and overlapping IP address sets, it
> >> will be problematic to install destinations from one ESI into the MAC-VRF
> in another ESI.
> >>
> >> The entire concept of aliasing appears dangerous to me. It would have
> >> been better to separate the MAC address from the EVI in two separate
> >> advertisements, making reachability to the MAC address in reference
> >> to the EVI, and reachabality to the EVI it's "own thing," rather than
> >> tying the two together and then creating an "alias."
> >>
> >> ==
> >> 8.5
> >>
> >> The definition of "service carving" is buried in the text in the
> >> middle of section 8.5. Shouldn't this be included in the glossary, at least?
> >>
> >> ==
> >> 8.5
> >>
> >> In step 3 of DF election, the list of IP addresses is ordered in
> >> "increasing numeric value." What if you have a mix of v4 and v6
> >> addresses?
> >>
> >> ==
> >>
> >> :-)
> >>
> >> Russ
> >>

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Mon, 2 Feb 2015 22:31:36 +0000

Fully agree with John.
Thanks.
Jorge

-----Original Message-----
From: John E Drake <[email-masked]>
Date: Monday, February 2, 2015 at 12:41 PM
To: Russ White <[email-masked]>, Jorge Rabadan
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [bess] EVPN Draft Comments

>> Two of these are going to be problems in real world deployments, and
>>need,
>> imho, to be fixed in a bis.
>> 
>> :-)
>> 
>> Russ
>> 
>>

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Mon, 2 Feb 2015 23:39:21 +0000

On 2/2/15 5:42 AM, "Russ White" <[email-masked]<mailto:[email-masked]>> wrote:

Y'all:

:::::::::::;

==
8.5

[Satya] One possible solution may be to do a lexicographic comparison of keys (the iP address strings in this case considered as sequence of bytes).
For unequal-length keys like in the case of v4 and v6, assume that a unique 'padding' alphabet is present after the v4 address that always has priority  over other alphabets (byte values).
This will make the comparison non-ambiguous, and still the same algorithm suffices.

==

:-)

Russ

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

Thanks,
--Satya

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Feb 2015 19:11:57 -0500

> MAC address length values other than 48 bits are outside the scope of this
> document."  So, The MAC Address field is a variable length field whose
> length is currently set to 48.

And the figure clearly shows the length at 6 octets only. I'm not arguing the draft didn't _intend_ to make this a variable length field -- I'm arguing the draft, as written, can easily be misinterpreted, and could use clarification.

> [JD]  Just because you don't like/understand it doesn't necessarily mean it's

John -- you could have said, "I think it's elegant because..." -- or, "I agree it's not perfect, but we chose this solution because..." Instead, you decided to launch a personal attack, calling me stupid/uneducated/ignorant/whatever. This is one of the things that drives me absolutely nuts about working in the IETF -- we cannot hold ourselves to an actual discussion, we have to find some way to make claims about other people personally, no matter whether or not we think they're true, etc. The next time someone says, "I can't figure out why we are losing participation in the IETF," go back and reread your response.

Now -- to return to the actual topic at hand -- I find the idea of binding things together tightly, and then creating an "alias," rather than creating a looser bind and map in the first place, is worse. That might not fit what you think, but it's still something worth mentioning.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Feb 2015 19:16:14 -0500

> "increasing
> [Satya] One possible solution may be to do a lexicographic comparison of
> keys (the iP address strings in this case considered as sequence of
bytes).
> For unequal-length keys like in the case of v4 and v6, assume that a
unique
> 'padding' alphabet is present after the v4 address that always has
priority
> over other alphabets (byte values).

Would you want a different DF for v4 and v6 devices? Maybe no -- because
this is layer 2 forwarding, but maybe yes. If the answer is no, then this
should be documented, I think, even if it's in a different doc.

:-)

Russ

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Tue, 3 Feb 2015 00:30:18 +0000

On 2/2/15 4:16 PM, "Russ White" <[email-masked]<mailto:[email-masked]>> wrote:

This will make the comparison non-ambiguous, and still the same algorithm
suffices.

[Satya] I believe a different DF for v4 and v6 is unnecessary (this is layer 2 forwarding as you pointed out, and I wrote the above keeping that in mind). The above method should work and can be documented (to remove unambiguity).
FYI, it may help to know there are other DF election procedures that are being worked on that are provably more robust, and do not have the problem discussed here.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Feb 2015 19:32:56 -0500

> [Satya] I believe a different DF for v4 and v6 is unnecessary (this is
layer 2
> forwarding as you pointed out, and I wrote the above keeping that in
mind).
> The above method should work and can be documented (to remove
> unambiguity).
> FYI, it may help to know there are other DF election procedures that are
> being worked on that are provably more robust, and do not have the
> problem discussed here.

That's great -- thanks! If y'all are working on a different doc, I would
just leave it 'til the alternates doc is published. Just wanted to make
certain it's covered at some point.

:-)

Russ

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 00:42:38 +0000

Russ,

Comments inline

Yours Irrespectively,

John

> From: Russ White [mailto:[email-masked]]
> Sent: Monday, February 02, 2015 7:12 PM
> To: John E Drake; 'Rabadan, Jorge (Jorge)'
> Cc: [email-masked]
> > MAC address length values other than 48 bits are outside the scope of
> > this document."  So, The MAC Address field is a variable length field
> > whose length is currently set to 48.
> 
> And the figure clearly shows the length at 6 octets only. I'm not arguing the
> draft didn't _intend_ to make this a variable length field -- I'm arguing the
> draft, as written, can easily be misinterpreted, and could use clarification.

[JD]  The field is six octets.  What is contained within the field is six octets today
but may be less in the future.  AFAIK this is consistent w/ standard IETF design, e.g.,
CIDR.

> John -- you could have said, "I think it's elegant because..." -- or, "I agree it's
> not perfect, but we chose this solution because..." Instead, you decided to
> launch a personal attack, calling me stupid/uneducated/ignorant/whatever.
> This is one of the things that drives me absolutely nuts about working in the
> IETF -- we cannot hold ourselves to an actual discussion, we have to find
> some way to make claims about other people personally, no matter whether
> or not we think they're true, etc. The next time someone says, "I can't figure
> out why we are losing participation in the IETF," go back and reread your
> response.
> 
> Now -- to return to the actual topic at hand -- I find the idea of binding things
> together tightly, and then creating an "alias," rather than creating a looser
> bind and map in the first place, is worse. That might not fit what you think,
> but it's still something worth mentioning.

[JD]  Your chastisement of my egregious behavior would have been more compelling if
you had provided any technical arguments for why the current design has issues or flaws.

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Feb 2015 19:53:18 -0500

> > And the figure clearly shows the length at 6 octets only. I'm not
> > arguing the draft didn't _intend_ to make this a variable length field
> > -- I'm arguing the draft, as written, can easily be misinterpreted, and
could
> use clarification.
> 
> [JD]  The field is six octets.  What is contained within the field is six
octets
> today but may be less in the future.  AFAIK this is consistent w/ standard
IETF
> design, e.g., CIDR.

CIDR is yet another mess -- not a good example, IMHO.

So the field is a _maximum_ of six octets, and potentially shorter? This
isn't explained in the document at all, and it should be.

> [JD]  Your chastisement of my egregious behavior would have been more
> compelling if you had provided any technical arguments for why the current
> design has issues or flaws.

There is a difference between "flawed" and "not elegant." It will work, but
I think it would have been cleaner/more elegant if the binding would have
been "loose," with a "connector," rather than the alias construction.
Aliases seem simple, but they add complexity in terms of ossification later
on -- they are more difficult to change in the future. 

Either way, a technical discussion is not the place to insert claims of
someone else being ignorant, etc.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Feb 2015 19:55:01 -0500

> CIDR is yet another mess -- not a good example, IMHO.

Sorry -- SIDR, not CIDR. Typed it back out without thinking, but it is
important to be precise.

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 00:25:07 -0500

Russ and John:

I have concerns about the issues Russ has raised as well as other concerns
regarding the EVPN.   As I mentioned at the last IETF's BESS meeting, John
Scudder and I have been discussing the next-hop issues in BESS drafts to see
if IDR could create better BGP mechanism for the future BESS drafts.   In
this review, it became clear that several of the mechanism in EVPN could
have been done in a simpler and more elegant way in BGP.    It was not the
first EVPN specification that made this clear, but the review of several
drafts. 

I am pragmatic.  It is auth-48. If the EVPN  is widely shipping and deployed
in networks, it is unlikely that the vendors or providers want to change it
at this point.  They have coded the EVPN solution.  My agreement with the
BESS chairs was this investigation was not to derail their work.     

If you are interested, I would appreciate a phone conversation with both of
you.  John Scudder indicated that John Drake would be the best person within
Juniper to discuss this point with.  Perhaps we can talk about all of these
issues.  Since it is a BGP mechanism, perhaps if we create a more elegant
BGP mechanism it could be considered as a "bis" for EVPN drafts.  I suspect
EVPN use is only going to grow, and better BGP mechanisms usually mean more
efficient and scalable code.  

Best wishes, 

Sue Hares 

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Russ White
Sent: Monday, February 02, 2015 7:12 PM
To: 'John E Drake'; 'Rabadan, Jorge (Jorge)'
Cc: [email-masked]
Subject: Re: [bess] EVPN Draft Comments

> whose length is currently set to 48.

And the figure clearly shows the length at 6 octets only. I'm not arguing
the draft didn't _intend_ to make this a variable length field -- I'm
arguing the draft, as written, can easily be misinterpreted, and could use
clarification.

> [JD]  Just because you don't like/understand it doesn't necessarily 

John -- you could have said, "I think it's elegant because..." -- or, "I
agree it's not perfect, but we chose this solution because..." Instead, you
decided to launch a personal attack, calling me
stupid/uneducated/ignorant/whatever. This is one of the things that drives
me absolutely nuts about working in the IETF -- we cannot hold ourselves to
an actual discussion, we have to find some way to make claims about other
people personally, no matter whether or not we think they're true, etc. The
next time someone says, "I can't figure out why we are losing participation
in the IETF," go back and reread your response.

Now -- to return to the actual topic at hand -- I find the idea of binding
things together tightly, and then creating an "alias," rather than creating
a looser bind and map in the first place, is worse. That might not fit what
you think, but it's still something worth mentioning.

:-)

Russ

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 3 Feb 2015 07:32:44 +0000

Russ,

It is good that you have started to read this draft several times recently
and asking the questions that should have been asked during the WG state
or even during the WG LC. But Adrian ask was very clear and specific wrt
section 6.3 and we am not opening this document for yet another round of
comments specially considering that this draft has been around for several
years in WG state. More in line ...

On 2/2/15, 4:11 PM, "Russ White" <[email-masked]> wrote:

>
>> [JD]  What RFC 7432 actually says is:  "The MAC Address Length field is
>>in bits,
>> and it is set to 48.
>>this
>arguing the draft, as written, can easily be misinterpreted, and could
>use clarification.

Wrt this draft, the text is very clear as it has been implemented by
several major vendors. Now if you are wondering what would be the
application for variable length, that is outside of the scope of this
draft as the draft clearly says that. However, if variable length is used,
the length field is basically the length of subnet address within the 6
octets w/ remaining bits set to zero. This may not be clear to you but
that doesn¹t make the existing text inaccurate.

>
>> [JD]  Just because you don't like/understand it doesn't necessarily
>>mean it's
>> wrong.
>
>agree it's not perfect, but we chose this solution because..." Instead,
>you decided to launch a personal attack, calling me
>stupid/uneducated/ignorant/whatever. This is one of the things that
>drives me absolutely nuts about working in the IETF -- we cannot hold
>ourselves to an actual discussion, we have to find some way to make
>claims about other people personally, no matter whether or not we think
>they're true, etc. The next time someone says, "I can't figure out why we
>are losing participation in the IETF," go back and reread your response.

Ross, if you don't like John's response, then you should probably take a
look at your email. You didn¹t ask your question(s) but rather asserting
that "the solution is not elegant².

-Ali 

>
>Now -- to return to the actual topic at hand -- I find the idea of
>binding things together tightly, and then creating an "alias," rather
>than creating a looser bind and map in the first place, is worse. That
>might not fit what you think, but it's still something worth mentioning.
>
>:-)
>
>Russ
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 3 Feb 2015 07:51:58 +0000

Sue,

>first EVPN specification that made this clear, but the review of several

If there are any specific suggestions, I¹d like to hear it. At the IETF
BESS meeting, I believe I didn¹t hear anything specific.

>BESS chairs was this investigation was not to derail their work.

It should be noted that this draft was written in collaboration with our
BGP colleagues: Yakov, Pedro, and Keyur right from the beginning. So, if
there are any issues, I am sure not just me but these folks would also be
interested in hearing them.

Regards,
Ali
  
>> mean it's wrong.
>you

---

From: Ravi Shekhar <[email-masked]>
Date: Tue, 3 Feb 2015 08:23:37 +0000

Hi Russ, as someone who was involved early on in the EVPN, I can assure you that we had considered load-balancing as achieved via aliasing early on in the process. John may not be aware of it because it pre-dates his involvement with EVPN, but please see section 20.1 of https://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-01#section-20.1. And you will find that it describes the aliasing functionality as far back as Nov 2010. So it is more than 4 years old, if not older - and if you look at that draft, same holds for other major concepts introduced in EVPN.

Thanks.
- Ravi Shekhar.

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Monday, February 02, 2015 12:41 PM
To: Russ White; Rabadan, Jorge (Jorge)
Cc: [email-masked]
Subject: Re: [bess] EVPN Draft Comments

Russ,

Comments inline.    

Yours Irrespectively,

John

> If the length of the layer 2 address is fixed, there is no way to 
> accommodate future use cases regardless of the inclusion of a length 
> field. The way the draft is written, it would be justifiable to ignore 
> the length field, destroying future expansion. Adding a length field 
> to a fixed length filed doesn't mean the length of the fixed length 
> field can change -- otherwise it wouldn't be fixed length.

[JD]  What RFC 7432 actually says is:  "The MAC Address Length field is in bits, and it is set to 48.
MAC address length values other than 48 bits are outside the scope of this document."  So, The MAC Address field is a variable length field whose length is currently set to 48.  

> relationships well, so let's throw in a way to get around the 
> limitations we put into the original draft." This isn't an elegant solution.

> 
> If the esi must be unique, and it's important, then the esi must be 
> unique as used. Using a non-unique part of the esi destroys the point 
> of building a unique esi in the first place.

[JD]  The ESI is unique.  The ES-Import RT is not.  This means that some PEs may import an Ethernet Segment route that are not attached to the ES specified in the Ethernet Segment route.  When they examine the Ethernet Segment route they will realize this and discard it.

> need, imho, to be fixed in a bis.
> 
> :-)
> 
> Russ
> 
> 
> > Section 7.2 - the mac length field is fixed in EVPN to 48, but it 
> > has to be there to allow future use-cases. For instance, it might 
> > make sense to use variable mac lengths in PBB-EVPN since the BMACs 
> > are
> operator-managed.
> >
> >
> > Section 7.6 - this is not an issue to me. The ESI has to be unique 
> > in the network. The mechanisms to auto-derive the ESI can only be 
> > used if they guarantee the uniqueness of the ESI. And since the 
> > ES-import route-target is a route-target, its value can only be 
> > present on the PEs where you want to import the route. I don’t think 
> > there is a need for clarification of the text.
> >
> >> these docs a number of times, and still come up with questions that 
> >> I think need to be addressed/answered at some point. In general, 
> >> eVPN seems to be on the receiving end of "I can imagine a lot of 
> >> different use cases, some of which are self-contradictory, but 
> >> let's just throw it all in the bucket anyway, regardless of the 
> >> complexity and other problems." But, aside from that -- some 
> >> specific comments on the base draft --
> >>
> >> ==
> >> Section 7.2
> >>
> >> The MAC address field in the TLV is specified as 6 octets, but 
> >> there is also a MAC address length field -- normally you would only 
> >> include a length field if the field itself is variable length, 
> >> which doesn't appear to be the case here. Is there some specific 
> >> reason a length field is included, and the length of the field is specified?
> >>
> >> ==
> >> Section 7.6
> >>
> >> This is a new transitive Route Target extended community carried 
> >> with the Ethernet Segment route. When used, it enables all the PEs 
> >> connected to the same multi-homed site to import the Ethernet 
> >> Segment routes. The value is derived automatically from the ESI by 
> >> encoding the high order 6-octet portion of the 9-octet ESI Value in 
> >> the ESImport Route Target. The high order 6-octet of the ESI 
> >> incorporates MAC address of ESI (for type 1, 2, and 3) which when 
> >> encoded in this RT and used in the RT constrain feature, it enables 
> >> proper routetarget filtering. The format of this extended community 
> >> is as
> >> follows:
> >>
> >> we're dealing with MAC addresses and overlapping IP address sets, 
> >> it will be problematic to install destinations from one ESI into 
> >> the MAC-VRF
> in another ESI.
> >>
> >> The entire concept of aliasing appears dangerous to me. It would 
> >> have been better to separate the MAC address from the EVI in two 
> >> separate advertisements, making reachability to the MAC address in 
> >> reference to the EVI, and reachabality to the EVI it's "own thing," 
> >> rather than tying the two together and then creating an "alias."
> >>
> >> ==
> >> 8.5
> >>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 06:12:39 -0500

Ali:

I would be glad to inform Yakov, Keyur and Pedro of these issues I perceive
with the draft.  It would be delightful to see why they thought your
structure was reasonable. 
 
Yakov and Pedro have not been in active discussions regarding IDR next-hop
mechanisms in the last year.  For 2014, Keyur and others on the IDR list
have been discussing new next-hop drafts.  I suggest you consult the IDR
mail list for these discussion regarding that the following draft. 

https://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/

At: 
http://www.ietf.org/mail-archive/web/idr/current/msg13658.html  (my
comments) 
http://www.ietf.org/mail-archive/web/idr/current/msg13689.html  (Eric
Rosen's) 

Eric Rosen raises some very useful points on this specific draft, and the
design of reliable next-hop mechanism.  It is Eric's comments and others
that have caused me to start a conversation regarding this topic.  

 Please note I lead this discussion on the EVPN with a pragmatic note.   If
the EVPN is deployed and implemented by 2 vendors (as we require for IDR WC
LC of protocol standards), then it should be standard rather than sit on the
shelf.  We can consider a revised BGP mechanism in the future, but it must
be deemed more efficient or better scaling. 

Best wishes, 

Sue 

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, February 03, 2015 2:52 AM
To: Susan Hares; 'Russ White'; 'John E Drake'; 'Rabadan, Jorge (Jorge)'
Cc: [email-masked]
Subject: Re: [bess] EVPN Draft Comments

Sue,

On 2/2/15, 9:25 PM, "Susan Hares" <[email-masked]> wrote:

>first EVPN specification that made this clear, but the review of 
>several drafts.

If there are any specific suggestions, I¹d like to hear it. At the IETF BESS
meeting, I believe I didn¹t hear anything specific.

> 
>
>I am pragmatic.  It is auth-48. If the EVPN  is widely shipping and 
>deployed in networks, it is unlikely that the vendors or providers want 
>to change it at this point.  They have coded the EVPN solution.  My 
>agreement with the BESS chairs was this investigation was not to derail 
>their work.

It should be noted that this draft was written in collaboration with our BGP
colleagues: Yakov, Pedro, and Keyur right from the beginning. So, if there
are any issues, I am sure not just me but these folks would also be
interested in hearing them.

Regards,
Ali
  
>  
>
>If you are interested, I would appreciate a phone conversation with 
>both of you.  John Scudder indicated that John Drake would be the best 
>person within Juniper to discuss this point with.  Perhaps we can talk 
>about all of these issues.  Since it is a BGP mechanism, perhaps if we 
>create a more elegant BGP mechanism it could be considered as a "bis" 
>for EVPN drafts.  I suspect EVPN use is only going to grow, and better 
>BGP mechanisms usually mean more efficient and scalable code.
>
>Best wishes,
>
>Sue Hares
>
>could use clarification.
>John -- you could have said, "I think it's elegant because..." -- or, 
>"I agree it's not perfect, but we chose this solution because..." 
>Instead, you decided to launch a personal attack, calling me 
>they're true, etc.
>The
>next time someone says, "I can't figure out why we are losing 
>participation in the IETF," go back and reread your response.
>

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 11:59:27 +0000

Sue,

It would be helpful if both you and Russ would offer some specifics.  E.g., the next hop issue that you mentioned in the BESS meeting has nothing to do w/ the base EVPN spec.

Yours Irrespectively,

John

> From: Susan Hares [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2015 12:25 AM
> To: 'Russ White'; John E Drake; 'Rabadan, Jorge (Jorge)'
> Cc: [email-masked]
> first EVPN specification that made this clear, but the review of several drafts.
> 
> I am pragmatic.  It is auth-48. If the EVPN  is widely shipping and deployed in
> networks, it is unlikely that the vendors or providers want to change it at this
> point.  They have coded the EVPN solution.  My agreement with the
> you.  John Scudder indicated that John Drake would be the best person
> within Juniper to discuss this point with.  Perhaps we can talk about all of
> these issues.  Since it is a BGP mechanism, perhaps if we create a more
> elegant BGP mechanism it could be considered as a "bis" for EVPN drafts.  I
> suspect EVPN use is only going to grow, and better BGP mechanisms usually
> mean more efficient and scalable code.
> 
> Best wishes,
> 
> Sue Hares
>

---

From: "Russ White" <[email-masked]>
Date: Tue, 3 Feb 2015 07:16:54 -0500

> Wrt this draft, the text is very clear as it has been implemented by
several
> major vendors. Now if you are wondering what would be the application for
> variable length, that is outside of the scope of this draft as the draft
clearly
> says that. However, if variable length is used, the length field is
basically the
> length of subnet address within the 6 octets w/ remaining bits set to
zero.
> This may not be clear to you but that doesn¹t make the existing text
> inaccurate.

The way I read the draft and the figures -- and what John has said -- is
this -- the field is fixed at 6 octets, but the address could be shorter,
though what you would do with a shorter address is outside the scope of the
draft. IMHO, the draft should either say --

- The field is variable length with a single option for a 6 octet address in
the first instance.
- The field is fixed to 6 octets -- in which case I'm not certain what the
length field is for.

> Russ, if you don't like John's response, then you should probably take a
look
> at your email. You didn¹t ask your question(s) but rather asserting that
"the
> solution is not elegant².

> >might not fit what you think, but it's still something worth mentioning.

Again -- the idea of an "alias" is less elegant than simply making a loose
binding or a "grouping," of like things with similar attributes. I
understand this may (sadly) already be implemented, so I'm not asking for a
change -- just pointing out that this isn't an ideal way of going about
building such things, and that we should avoid them in the future. 

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 07:27:36 -0500

John - 

Irrespectively - I cut the email list from the [email-masked] working group
and I will not bring it back unless instructed by the BESS WG chairs.  The
Base EVPN does not utilize the NLRI/Attributes in a way I consider standard
BGP mechanism to allow scaling or efficient processing. However, I promised
the BESS WG chairs that until I did a complete write-up,  I would state
concerns briefly (aka agreeing with Russ) but not delay any standardization
work on the current drafts.  

Due to fulfill promise, I did not comment during IETF LC / WG LC because I
had not written up my comments on each draft as an IETF Draft.  If you wish
to engage in a conversation prior to me writing an Internet draft - I
welcome it.    

Pragmatically, 

Sue 

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Tuesday, February 03, 2015 6:59 AM
To: Susan Hares; 'Russ White'; 'Rabadan, Jorge (Jorge)'
Cc: [email-masked]
Subject: Re: [bess] EVPN Draft Comments

Sue,

It would be helpful if both you and Russ would offer some specifics.  E.g.,
the next hop issue that you mentioned in the BESS meeting has nothing to do
w/ the base EVPN spec.

Yours Irrespectively,

John

drafts.
> deployed in networks, it is unlikely that the vendors or providers 
> want to change it at this point.  They have coded the EVPN solution.  
> My agreement with the BESS chairs was this investigation was not to derail
their work.
> > MAC address length values other than 48 bits are outside the scope 
> > of this document."  So, The MAC Address field is a variable length 
> > field whose length is currently set to 48.
> 
could use clarification.
> Instead, you decided to launch a personal attack, calling me
stupid/uneducated/ignorant/whatever.
> This is one of the things that drives me absolutely nuts about working 
> in the IETF -- we cannot hold ourselves to an actual discussion, we 
> have to find some way to make claims about other people personally, no 
> matter whether or not we think they're true, etc. The next time 
> someone says, "I can't figure out why we are losing participation in 
> the IETF," go back and reread your response.
>

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 12:47:44 +0000

Sue,

I think we have a tempest in a teapot.

The EVPN Overlay draft (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00) needs to indicate different data plane encapsulations and initially we had proposed using the RFC 5512 extended community for this.  

Subsequently, Ali and Keyur proposed using Keyur's remote next hop draft which you reference, below, because it also specifies data plane encapsulations.  Ultimately, and w/ Yakov's assistance, we re-affirmed our decision to use the RFC 5512 extended community and I believe that the necessary additional code points have been allocated. 

So to recap, we have no interest in or any need for remote next hops.  

Yours Irrespectively,

John

> Sent: Tuesday, February 03, 2015 6:13 AM
> To: 'Ali Sajassi (sajassi)'; 'Russ White'; John E Drake; 'Rabadan, Jorge (Jorge)'
> Cc: [email-masked]
> with the draft.  It would be delightful to see why they thought your structure
> was reasonable.
> 
> mechanisms in the last year.  For 2014, Keyur and others on the IDR list have
> been discussing new next-hop drafts.  I suggest you consult the IDR mail list
> for these discussion regarding that the following draft.
>

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 13:03:34 +0000

Russ,

I think the real issue may be some baggage you associate w/ the term 'alias'.

In EVPN, the combination of a Per ES and a Per EVI Ethernet AD route indicates that the advertising PE has connectivity to a given ES and that the advertised MPLS label can be used to reach any MAC addresses associated w/ the [ES, EVI].  The reason for this is that, as the draft points out, the PEs attached to a given ES have no control over to which PEs the CE sends data and hence a given PE may not see a particular CE MAC address.    

Yours Irrespectively,

John

> Sent: Tuesday, February 03, 2015 7:17 AM
> To: 'Ali Sajassi (sajassi)'; John E Drake; 'Rabadan, Jorge (Jorge)'
> Cc: [email-masked]
> > major vendors. Now if you are wondering what would be the application
> > for variable length, that is outside of the scope of this draft as the
> > draft
> clearly
> The way I read the draft and the figures -- and what John has said -- is this --
> the field is fixed at 6 octets, but the address could be shorter, though what
> you would do with a shorter address is outside the scope of the draft. IMHO,
> the draft should either say --
> 
> - The field is variable length with a single option for a 6 octet address in the
> first instance.
> - The field is fixed to 6 octets -- in which case I'm not certain what the length
> field is for.
> 
> > >than creating a looser bind and map in the first place, is worse.
> > >That might not fit what you think, but it's still something worth
> mentioning.
> 
> binding or a "grouping," of like things with similar attributes. I understand this
> may (sadly) already be implemented, so I'm not asking for a change -- just
> pointing out that this isn't an ideal way of going about building such things,
> and that we should avoid them in the future.
> 
> :-)
> 
> Russ
> 
>

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 13:12:52 +0000

Sue,

Comments inline.

Yours Irrespectively,

John

> Sent: Tuesday, February 03, 2015 7:28 AM
> To: John E Drake; 'Russ White'; 'Rabadan, Jorge (Jorge)'
> Cc: [email-masked]
> Irrespectively - I cut the email list from the [email-masked] working group and I
> will not bring it back unless instructed by the BESS WG chairs.

[JD]  No you didn't. 

> The Base EVPN
> does not utilize the NLRI/Attributes in a way I consider standard BGP
> mechanism to allow scaling or efficient processing.

[JD]  As I said I would like to see specifics - all I see is an assertion of FUD .   

> However, I promised the
> BESS WG chairs that until I did a complete write-up,  I would state concerns
> briefly (aka agreeing with Russ) but not delay any standardization work on
> the current drafts.

[JD]  If you are saying that your concerns are the same as those of Russ, then I don't think we have any issues. 

> It would be helpful if both you and Russ would offer some specifics.  E.g., the
> next hop issue that you mentioned in the BESS meeting has nothing to do w/
> the base EVPN spec.
> 
> Yours Irrespectively,
> 
> John
> 
> > Scudder and I have been discussing the next-hop issues in BESS drafts
> > to
> see

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 13:36:30 +0000

Ravi,

Thanks but I think you misread my email.  I was actually pointing out to Russ that he hadn't expressed anything more than a visceral dislike for the current EVPN aliasing design. 

Yours Irrespectively,

John

> From: Ravi Shekhar
> Sent: Tuesday, February 03, 2015 3:24 AM
> To: John E Drake; Russ White; Rabadan, Jorge (Jorge)
> Cc: [email-masked]
> Hi Russ, as someone who was involved early on in the EVPN, I can assure you
> that we had considered load-balancing as achieved via aliasing early on in the
> process. John may not be aware of it because it pre-dates his involvement
> with EVPN, but please see section 20.1 of https://tools.ietf.org/html/draft-
> raggarwa-sajassi-l2vpn-evpn-01#section-20.1. And you will find that it
> describes the aliasing functionality as far back as Nov 2010. So it is more than
> 4 years old, if not older - and if you look at that draft, same holds for other
> major concepts introduced in EVPN.
> 
> Thanks.
> - Ravi Shekhar.
> 
> [JD]  The ESI is unique.  The ES-Import RT is not.  This means that some PEs
> may import an Ethernet Segment route that are not attached to the ES
> specified in the Ethernet Segment route.  When they examine the Ethernet
> Segment route they will realize this and discard it.
> 
> 
> >

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 3 Feb 2015 14:05:55 +0000

To add to what John said, the remote NH proposal would be less efficient
than the EVPN draft in terms of BGP messaging.

On 03/02/15 13:47, "John E Drake" <[email-masked]> wrote:

>The EVPN Overlay draft
>(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00) needs to
>indicate different data plane encapsulations and initially we had
>proposed using the RFC 5512 extended community for this.
>
>Subsequently, Ali and Keyur proposed using Keyur's remote next hop draft
>which you reference, below, because it also specifies data plane
>encapsulations.  Ultimately, and w/ Yakov's assistance, we re-affirmed
>our decision to use the RFC 5512 extended community and I believe that
>the necessary additional code points have been allocated.
>
>>structure
>> >to see
>>BESS

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 3 Feb 2015 17:37:47 +0000

Hi Sue,

Two points:

1) What you are saying below and the draft that you mentioned below
(idr-remote-next-hop) is not relevant to baseline EVPN draft (soon to be
RFC 7432). 

2) At one point we were thinking of using this draft for evpn-overlay
draft (which is different from baseline evpn); however, we decided not to
use it and instead use RFC5512. That decision was made about a year ago.

Regards,
Ali

On 2/3/15, 3:12 AM, "Susan Hares" <[email-masked]> wrote:

>BGP

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 13:51:26 -0500

Ali:

Ok - I will answer a direct question on the EVPN RFC, and then may we please
stop this thread.  

I understood that Russ was referring to the EVPN draft (soon to be RFC
7432).   I am not referring to the evpn-overlay draft, and this is not "the
nexthop" issue.    This is Auth-48, and the draft is going to be an RFC (per
IETF procedures).   EVPNs are important to the industry and the
standardization of these features are important.   Clarity is important for
the base draft and other draft to assure proper interoperability in testing
and deployment.  Delaying this draft is not good for the industry.   I
believe we both want the best possible BGP mechanisms to better fit the EVPN
environment is.   

>>-- I'm arguing the draft, as written, can easily be misinterpreted, and

My original post only confirmed that I felt like Russ the text could have
been improved.  I just wanted to confirm I that I shared Russ' perceptions
of the unclarity of the text.  BGP is flexible things, and as you know, BGP
attributes and AFIs can be done in many ways so this makes clarity important
in BGP drafts.     

All the rest of these post was to answer other direction questions you or
your co-authors posed which were off the topic of the base EVPN RFC. For
that, I apologize to the BESS list for the spam.   

Sue  

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Tuesday, February 03, 2015 12:38 PM
To: Susan Hares; 'Russ White'; 'John E Drake'; 'Rabadan, Jorge (Jorge)'
Cc: [email-masked]
Subject: Re: [bess] EVPN Draft Comments

Hi Sue,

Two points:

1) What you are saying below and the draft that you mentioned below
(idr-remote-next-hop) is not relevant to baseline EVPN draft (soon to be RFC
7432). 

2) At one point we were thinking of using this draft for evpn-overlay draft
(which is different from baseline evpn); however, we decided not to use it
and instead use RFC5512. That decision was made about a year ago.

Regards,
Ali

On 2/3/15, 3:12 AM, "Susan Hares" <[email-masked]> wrote:

>Ali:
>
>I would be glad to inform Yakov, Keyur and Pedro of these issues I 
>perceive with the draft.  It would be delightful to see why they 
>thought your structure was reasonable.
> 
>Yakov and Pedro have not been in active discussions regarding IDR 
>next-hop mechanisms in the last year.  For 2014, Keyur and others on 
>the IDR list have been discussing new next-hop drafts.  I suggest you 
>consult the IDR mail list for these discussion regarding that the following
draft.

---

From: Russ White <[email-masked]>
Date: Tue, 3 Feb 2015 15:26:35 -0500

I'm on an iPad, so forgive the top post, but this is what I dug up from an email I sent a year+ ago, with some edits added, about aliasing as I understand it. It was never answered, afaict.

==
Let's say you have PE A, B, and C attached to a single ES. The first problem is -- under what conditions would a host, say X, send a packet to A and not to the others? This must be some sort of segment where no broadcasts are transmitted, somX discovers A through manual configuration or some such. This is a vanishingly small corner case, so I'm not certain this is worth dealing with in the main draft.
 
But let's assume it is… the process described in the draft is that A will "alias" itself to B and C, such that the hosts it knows about are reported to be attached to all three. But if A itself fails, the hosts it has learned will be withdrawn, leaving the aliased destinations stranded, and hence they will need to be withdrawn from the table until they send some ne packet and thus readvertised by either B or C, and then another aliasing arrangement set up. This is painful.
 
What would seem to be better would be for something like a type 2 or DIS to be used. A, B, and C would all advertise connection to the ES, and then A would advertise a connection between the ES and each host it knows about, etc. As B receives this advertisement, it can inject this information into its local Mac table, so that if A fails the reachable destination point doesn't change, only the attachment point.
 
How safe this all is depends on how much you trust the concept of an ES without broadcast capabilities, or rather that this device X will be able to receive unicast from A, B, and C, but B and C will never see a packet from X so long as A is available.
==

My thinking is that we're too late in the process to change this draft, but that a general revisiting of the aliasing idea in a potential separate draft might be worth the time and effort.

:-)

Russ

---

From: Ravi Shekhar <[email-masked]>
Date: Tue, 3 Feb 2015 21:07:08 +0000

Hi Russ, please see inline.

From: Russ White [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 12:27 PM
To: John E Drake
Cc: Ravi Shekhar; Rabadan, Jorge (Jorge); [email-masked]
Subject: Re: [bess] EVPN Draft Comments

==

<Ravi> The grat-ARP or first flow from X will only go out on one of the LAG links – i.e. to PE A/B or C. This is not a corner case.

<Ravi> Using a route from another PE (A here) to inject a route by other PEs (B/C) has its pitfalls. For instance withdrawals are going to be tough. Say A has died for good, and X goes away – what mechanism will invalidate this route from B? If it is local-aging at B, then B might as well use local-learning to advertise the route in the first place.

<Ravi> In most practical situations, X would rehash its flow to B/C if A has died. And B/C will learn the MAC of X (if they already hadn’t due to other flows), and will publish the route again (if they already hadn’t).

<Ravi> Thanks.

<Ravi> - Ravi Shekhar.

:-)

Russ

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 21:14:02 +0000

Russ,

Comments inline.

Yours Irrespectively,

John

From: Russ White [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 3:27 PM
To: John E Drake
Cc: Ravi Shekhar; Rabadan, Jorge (Jorge); [email-masked]
Subject: Re: [bess] EVPN Draft Comments

==

[JD]  The RFC contains multiple examples of why this might happen.

[JD]   That’s not how it works.  A, B, and C will advertise connectivity to the ES in question, A will advertise MAC address X , and B and C will advertise MPLS labels for the EVI in question.

An ingress PE will build an forwarding entry for MAC address X, w/ next hops A, B, and C and a reference count of the number of PEs advertising X.  If A loses connectivity to the ES in question or it fails, its MAC advertisement for X will be withdrawn .  An ingress PE will decrement its reference count, see that it is zero, and remove the forwarding entry.

I.e.,  MAC Advertisement routes cause a forwarding entry to be either created or its reference count to be incremented.  MAC Advertisement route withdrawals cause a forwarding entry’s reference count to be decremented or cause a forwarding entry to be deleted.  Per EVI Ethernet AD routes and their withdrawals cause next hops to be created or deleted.

:-)

Russ

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Feb 2015 21:24:42 +0000

Snipped, comment inline.

Yours Irrespectively,

John

<Ravi> Thanks.

<Ravi> - Ravi Shekhar.

[JD]  We briefly considered this in the spring of 2012 and decided it was a really bad idea for many reasons, including the one Ravi describes above.

---

From: "Russ White" <[email-masked]>
Date: Tue, 3 Feb 2015 22:47:13 -0500

> <Ravi> Using a route from another PE (A here) to inject a route by other PEs
> (B/C) has its pitfalls. For instance withdrawals are going to be tough. Say A
> has died for good, and X goes away – what mechanism will invalidate this
> route from B? If it is local-aging at B, then B might as well use local-learning to
> advertise the route in the first place.

This is pitfall in every conceivable scheme, in fact, when you have transmit capability to a device you can't see at the other end of the link to know it's actual status. If the CE and PE both fail at the same time when you're assuming connectivity you can't prove, you're always going to run into this problem -- including your aliasing scheme.

> <Ravi> In most practical situations, X would rehash its flow to B/C if A has
> died. And B/C will learn the MAC of X (if they already hadn’t due to other
> flows), and will publish the route again (if they already hadn’t).

So let's work through the process --

- A fails
- The advertisements A was sending are, after peer down, removed from the table
- X continues sending traffic until it either the session resets or (hopefully) the interface down on A propagates towards X in some way -- but there's no way of actually knowing what this looks like, as we don't have any idea what's actually between A and X
- Eventually, X begins refactoring it's hash, and starts sending towards B
- B learns the new attached host, and readvertises it

There is a lot of "ifs, ands, and buts," in here to cover, and a lot of time. Either both A and B can reach the same set of hosts, or they cannot. If they can, then the link should be treated as a broadcast, which means it's reachable from every upstream on the LAG connected to it. I would still prefer a solution that doesn't play this sort of "I can reach all the same things he can," game -- the DR type of system is much cleaner, and much more robust to modifications and future enhancements than aliasing will be.

Of course, the real solution is -- don't use LAGs when you're doing layer 3 control plane mechanisms in the first place, but you must get out of the layer 2 only mindset to see that LAGs are causing you nothing but trouble all around in a proactive control plane with high density link counts. 

:-)

Russ

---

From: Ravi Shekhar <[email-masked]>
Date: Wed, 4 Feb 2015 07:37:19 +0000

The approach of A/B/C independently generating route to X only based on local MAC learning works even if physical link failure detection is not an option. And in most practical cases, X will have enough active flows that it will cause local learning on A/B/C to hopefully happen well before a failure of connection to A happens. In the event that this is not the case, current scheme takes care of it via ESI route. Can you elaborate when it does not work a bit more? 

There are other problems with the approach that you have cited - for instance, if the advertisement of route to X from A triggered B and C to generate route to X as well, what happens if X goes away? Phy-layer will not help A/B/C in the detection of X going away. A will keep its advertisement intact (even after X has aged out locally) because it is seeing route to X from B/C => much like B/C created the route to X based on A's advertisement initially. Similarly B/C will keep their routes intact because A's route is lingering around. There will be a circular dependency created and route to X will never get withdrawn. Not to mention, that even if this can be fixed with extra state and extra bits in the advertisement from B/C (which  may eventually make the scheme even complex),  advertisement of a route based on another route and keeping track of this dependency in the same route table will require a extra BGP machinery that does not exist today.

I would think that the closer a PE is to the source of information that causes it to generate a route - like local MAC learning for MAC route, or LAG link present for ESI route - the more accurate its information will be. The farther the PE is from the source of information - like a PE depending on another PE's route to generate its own MAC route - convergence will be slower and complexity will be higher to keep track of dependent state.

My 2 cents.
- Ravi.

-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: Tuesday, February 03, 2015 7:47 PM
To: Ravi Shekhar; John E Drake
Cc: 'Rabadan, Jorge (Jorge)'; [email-masked]
Subject: RE: [bess] EVPN Draft Comments

> (B/C) has its pitfalls. For instance withdrawals are going to be 
> tough. Say A has died for good, and X goes away – what mechanism will 
> invalidate this route from B? If it is local-aging at B, then B might 
> as well use local-learning to advertise the route in the first place.

> <Ravi> In most practical situations, X would rehash its flow to B/C if 
> A has died. And B/C will learn the MAC of X (if they already hadn’t 
> due to other flows), and will publish the route again (if they already hadn’t).

- A fails

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Wed, 4 Feb 2015 07:16:31 -0500

> The approach of A/B/C independently generating route to X only based on
> local MAC learning works even if physical link failure detection is not an
> option. And in most practical cases, X will have enough active flows that it will
> cause local learning on A/B/C to hopefully happen well before a failure of
> connection to A happens. In the event that this is not the case, current
> scheme takes care of it via ESI route. 

Then -- again, aliasing is covering a corner case, and I'm not certain of the value of this mechanism in the main draft.

> There are other problems with the approach that you have cited - for
> instance, if the advertisement of route to X from A triggered B and C to
> generate route to X as well, what happens if X goes away? Phy-layer will not
> help A/B/C in the detection of X going away. A will keep its advertisement
> intact (even after X has aged out locally) because it is seeing route to X from
> B/C => much like B/C created the route to X based on A's advertisement
> initially. Similarly B/C will keep their routes intact because A's route is
> lingering around. There will be a circular dependency created and route to X
> will never get withdrawn. Not to mention, that even if this can be fixed with
> extra state and extra bits in the advertisement from B/C (which  may
> eventually make the scheme even complex),  advertisement of a route
> based on another route and keeping track of this dependency in the same
> route table will require a extra BGP machinery that does not exist today.

Agreed -- Which is why this needs some brainstorming, rather than just adding something into BGP that is fragile in the first place. Another option might be --

- B sees A's advertisement with a MAC address it doesn't have in its local table, or hasn't learned
- B initiates an ARP or some other packet towards this MAC address
- If connectivity exists, normal MAC learning and advertisement now takes place

As you say -- 

> I would think that the closer a PE is to the source of information that causes it
> to generate a route - like local MAC learning for MAC route, or LAG link
> present for ESI route - the more accurate its information will be. The farther
> the PE is from the source of information - like a PE depending on another PE's
> route to generate its own MAC route - convergence will be slower and
> complexity will be higher to keep track of dependent state.

As aliasing suffers from the same criticism, it would seem, to me, that some other solution would be better overall, if we can find one. Hence my original comment that this appears not to be an elegant solution (IMHO), as it's assuming connectivity that may or may not exist, and needs more thought.

:-)

Russ

---

From: John E Drake <[email-masked]>
Date: Wed, 4 Feb 2015 12:38:28 +0000

Russ

Comments inline.  I think my original comment describes the state of play:  "Just because you don't like/understand it doesn't necessarily mean it's wrong.".    

Yours Irrespectively,

John

> Sent: Wednesday, February 04, 2015 7:17 AM
> > The approach of A/B/C independently generating route to X only based
> > on local MAC learning works even if physical link failure detection is
> > not an option. And in most practical cases, X will have enough active
> > flows that it will cause local learning on A/B/C to hopefully happen
> > well before a failure of connection to A happens. In the event that
> > this is not the case, current scheme takes care of it via ESI route.
> 
> Then -- again, aliasing is covering a corner case, and I'm not certain of the
> value of this mechanism in the main draft.

[JD]  Unsupported assertion 

> > instance, if the advertisement of route to X from A triggered B and C
> > to generate route to X as well, what happens if X goes away? Phy-layer
> > will not help A/B/C in the detection of X going away. A will keep its
> > advertisement intact (even after X has aged out locally) because it is
> > seeing route to X from B/C => much like B/C created the route to X
> > based on A's advertisement initially. Similarly B/C will keep their
> > routes intact because A's route is lingering around. There will be a
> > circular dependency created and route to X will never get withdrawn.
> > Not to mention, that even if this can be fixed with extra state and
> > extra bits in the advertisement from B/C (which  may eventually make
> > the scheme even complex),  advertisement of a route based on another
> > route and keeping track of this dependency in the same route table will
> require a extra BGP machinery that does not exist today.
> 
> Agreed -- Which is why this needs some brainstorming, rather than just
> adding something into BGP that is fragile in the first place. 

[JD]  Unsupported assertion 

> Another option might be --
> 

[JD]  This is a local node behavior option that is entirely consistent w/ aliasing as it is currently defined

> 
> As you say --
> 
> > I would think that the closer a PE is to the source of information
> > that causes it to generate a route - like local MAC learning for MAC
> > route, or LAG link present for ESI route - the more accurate its
> > information will be. The farther the PE is from the source of
> > information - like a PE depending on another PE's route to generate
> > its own MAC route - convergence will be slower and complexity will be
> higher to keep track of dependent state.
> 
> As aliasing suffers from the same criticism,

[JD]  Unsupported assertion  

> it would seem, to me, that some
> other solution would be better overall, if we can find one. Hence my original
> comment that this appears not to be an elegant solution (IMHO), as it's
> assuming connectivity that may or may not exist, and needs more thought.

[JD]  Unsupported assertion

---

From: "Russ White" <[email-masked]>
Date: Wed, 4 Feb 2015 08:06:35 -0500

> Comments inline.  I think my original comment describes the state of play:
> "Just because you don't like/understand it doesn't necessarily mean it's
> wrong.".

John -- Irrespectively, as you like to say -- again, calling me stupid isn't helping anything here.

> > > on local MAC learning works even if physical link failure detection
> > > is not an option. And in most practical cases, X will have enough
> > > active flows that it will cause local learning on A/B/C to hopefully
> > > happen well before a failure of connection to A happens. In the
> > > event that this is not the case, current scheme takes care of it via ESI
> route.
> >
> > Then -- again, aliasing is covering a corner case, and I'm not certain
> > of the value of this mechanism in the main draft.
> 

No, what we've had in this thread is --

"This is not a corner case, as it happens all the time with LAGS," followed by, "Any given host will have enough flows to prevent the long convergence time failure mode from happening," above. Which is it? 

> [JD]  Unsupported assertion

Are you actually reading the thread here, or just reacting emotionally?

> as it is currently defined

If a local node can solve the problem in a way that's cleaner than what aliasing provides, then why does the draft need aliasing in the first place?  Why are we pushing mechanisms into BGP for a problem that can be solved locally more efficiently and more reliably?

> [JD]  Unsupported assertion

Your assertion that my assertion is unsupported is, itself, unsupported.

John -- clearly you don't want to have a discussion, so there's no point in having a "nondiscussion" with you. I'll find Ravi at the next IETF, and we can have an intelligent conversation -- which is apparently only possible when you're not in the room.

Russ

---

From: John E Drake <[email-masked]>
Date: Wed, 4 Feb 2015 13:23:25 +0000

Russ,

> 
> John -- clearly you don't want to have a discussion, so there's no point in
> having a "nondiscussion" with you. I'll find Ravi at the next IETF, and we can
> have an intelligent conversation -- which is apparently only possible when
> you're not in the room.

[JD]  Excellent, sounds like a plan.  So we are done here?