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 > -----Original Message----- > From: Russ White [mailto:[email protected]] > Sent: Tuesday, February 03, 2015 7:17 AM > To: 'Ali Sajassi (sajassi)'; John E Drake; 'Rabadan, Jorge (Jorge)' > Cc: [email protected] > Subject: RE: [bess] EVPN Draft Comments > > > > 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². > > > >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. > > 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 > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
