[bess] Erik Kline's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-11: (with COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-bess-mvpn-evpn-aggregation-label-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

Hi Sasha, The point that I was trying to make in my response to Brian is that the mechanism for checking L2 Attribute (e.g., MTU) is independent of physical/virtual nature of ES and whatever procedure(s) that applies to physical ES, also applies to virtual ES. Now, if you have a question or

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

Ali and all, Just to make it clear: I support advancing the draft "as is". My earlier comments are just about the responses to one if Brian's comments. My 2c, Sasha Get Outlook for Android From: Alexander Vainshtein Sent: Sunday,

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

Ali and all, More of the same... IMHO and FWIW even the usage of EVPN L2 -Attributes Extended Community for "bridging" EVPN shall not address the issue raised by Brian because: 1. Just one IMET route is advertised per BD and so the information it carties cznnot be associated with any

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

Ali and all, I am concerned about Ali's response to one of Bryan's comments (copied below): MTU size, control word, flow label, and other L2 attributes are carried in EVPN L2-Attribute Extended Community which is sent along with IMET route or Ether A-D per EVI route. These are independent of