Hi Jorge,
Before I can reply to your inputs, request you to go through the below
information.
I need to understand if I am on the right track with respect to the points
mentioned in the RFC.
In my understanding of the RFC8584, I prefer to differ on the part where it
says the following -
RFC 8584 Sec 1.3.1
Unfair load-balancing
My entire draft is to prevent unfair load balancing.
It auto-corrects itself irrespective of the kind of vlans configured, that
is odd or even, and in whichever order.
It also reconverges whenever new vlan/s are commissioned or existing vlan/s
are decommissioned.
Service disruption
Disruption when VTEP goes down or crashes is disruption. Rest of the VTEPs
have to re-converge.
If we have to fix this, then we can have a stacked VTEP like a cluster. For
instance, a 3 unit cluster can have 1 Active unit and rest 2 as Hot-Standby
units.
If Active crashes, one of the Hot Standby takes over, (unplanned
switchover) quoting Graceful Restart language. All we need is a LAG
interface link to all the 3 units of the VTEP cluster.
Pls correct me if i am mis-aligned in getting what the author has tried to
convey wrt this content.
Sec 1.3.2
(i) What it says:
A given individual AC defined in an ES is accidentally shut down
or is not provisioned yet (hence, the ACS is DOWN), while the ES
is operationally active (since the ES route is active).
In our implementations, we always have the ES as a LAG interface. If the
LAG interface is shut or isnt provisioned yet,
then it is an operator error. The RFC clearly states that, the VTEPs within
an ES should be configured identically for the functionality to work
seamlessly.
There is a disclaimer in place exactly for these accidental or
co-incidental erros from the operator.
So this point being picked up for discussion in RFC8584...well i am not
able to get it...Again this is my understanding and thinking.
Pls feel free to correct me where ever necessary. I would be glad to
correct my understanding.
(ii) What it says:
This is because a logical failure in
PE2's AC2 may not trigger an ES route withdrawal for ES12 (since
there are still other ACs active on ES12); therefore, PE1 will
not rerun the DF election procedures.
I presume that the CE device and VTEP are always directly connected.
If the author thinks that the CE and VTEP may in-turn be connected by an L2
Switch in between, then I restate my case here as what the author says will
be fine, that is, if the Switch port
goes down, then VTEP will be unaware of it. So as VTEP doesn't react to
this event, the Peer will not re-trigger the DF election.
But if this isn't the case, and if the CE and VTEP are always directly
connected is a given fact, then there is no scope for a logical failure to
happen on a VTEP interface, or the interface being shut and the VTEP not
reacting on that. To be frank, my entire understanding is based on the fact
that there will always be re-convergence if ever the VTEP loses its ES
connection.
However, yes, there will be traffic outages for a few milliseconds till the
re-convergence happens...
But if this millisecond outage is a huge criteria, then my draft won't
stand a chance here....as the entire idea of achieving efficient
service-carving is triggered by re-convergence
which will always take a few milliseconds to re-converge.
Jorge, if my understanding here is wrong, then I will rest my draft here.
So, if I am mis-aligned in getting a few concepts right, kind request to
help me understand.
Really appreciate it if you can provide some inputs here.
However, if you feel that I do have few valid points, then do let me know.
I did be glad to reply to your inputs.
Thanks much in advance.
regards
Kiran
Regards
Kiran
On Wed, Feb 5, 2025 at 9:54 PM Kiran KT <kirank...@gmail.com> wrote:
> Hi Jorge
> Thanks much for the feedback.
> Will go through it.
>
> Regards
> Kiran
>
> On Mon, 3 Feb, 2025, 10:28 pm Jorge Rabadan (Nokia), <
> jorge.raba...@nokia.com> wrote:
>
>> Hi everyone,
>>
>>
>>
>> As requested by the chairs, I went through the text.
>>
>> Here are my comments, Kiran, in case they help:
>>
>>
>>
>> - The text introduces a new DF election algorithm to address the gaps
>> in the default algorithm defined in RFC 7432. However, it does not mention
>> HRW (RFC 8584) or compare the proposed approach to it, even though HRW was
>> introduced specifically to address these same gaps.
>> - The proposed DF algorithm appears to use only VLANs as input, which
>> means it would suffer from the same imbalance across ESes as the default
>> algorithm — one of the issues highlighted in RFC 8584 and one of the key
>> reasons for introducing HRW.
>> - The text states that the proposal is “backward compatible with the
>> procedures defined in RFC 7432,” but it does not clarify which specific
>> procedures it refers to.
>> - Also, this text does not seem correct to me (RFC7432 does not
>> support “capabilities” or different DF Election algorithms):
>>
>>
>>
>> “As suggested in RFC7432 <https://datatracker.ietf.org/doc/html/rfc7432>,
>> if any one of the PEs in the ES doesnt
>>
>> support this capability of this approach, all PEs can revert back
>>
>> to the default election algorithm type.”
>>
>>
>>
>> - The IANA section requests the allocation of type value 2 (!).
>> Please do not suggest the use of a value that is registered already in
>> IANA
>> for another algorithm. Please check out:
>>
>> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml,
>> DF Alg section.
>>
>>
>>
>> Overall, while the proposed algorithm may be useful in certain cases, I’m
>> not convinced that another approach is necessary to address issues already
>> handled by HRW—unless HRW is proven ineffective. Additionally, the document
>> overlooks the preference-based DF algorithm, which is widely used in
>> scenarios requiring full determinism and control in DF election.
>>
>>
>>
>> My two cents..
>>
>>
>>
>> Thanks.
>>
>> Jorge
>>
>>
>>
>>
>>
>>
>>
>> *From: *Matthew Bocci (Nokia) <matthew.bocci=40nokia....@dmarc.ietf.org>
>> *Date: *Wednesday, January 22, 2025 at 8:07 AM
>> *To: *kirank...@gmail.com <kirank...@gmail.com>, bess@ietf.org <
>> bess@ietf.org>
>> *Subject: *[bess] Re: Review request for draft - Efficient service
>> carving in Multi-homed Evpn networks
>>
>> Hi WG
>>
>>
>>
>> Just reminder to please take a look at this and provide feedback to the
>> author.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Matthew
>>
>>
>>
>>
>>
>> *From: *Kiran KT <kirank...@gmail.com>
>> *Date: *Saturday, 4 January 2025 at 09:25
>> *To: *bess@ietf.org <bess@ietf.org>
>> *Subject: *[bess] Re: Review request for draft - Efficient service
>> carving in Multi-homed Evpn networks
>>
>> You don't often get email from kirank...@gmail.com. Learn why this is
>> important <https://aka.ms/LearnAboutSenderIdentification>
>>
>>
>>
>>
>>
>> *CAUTION:* This is an external email. Please be very careful when
>> clicking links or opening attachments. See the URL nok.it/ext for
>> additional information.
>>
>>
>>
>> Hi BESS Team
>>
>>
>>
>> The draft discusses approaches on how efficient Service Carving can be
>> achieved in Multi-Homed EVPN networks.
>>
>> Kindly review and let me know your thoughts/comments on the same.
>>
>>
>> https://datatracker.ietf.org/doc/draft-kiran-bess-service-carving-evpn-multi-homing/
>>
>>
>>
>> Kindly note: Draft will expire in the last week of Jan 2025.
>>
>>
>>
>> Regards
>>
>> Kiran
>>
>>
>>
>>
>>
>> On Sun, Oct 20, 2024 at 2:15 AM Kiran KT <kirank...@gmail.com> wrote:
>>
>> Hi BESS Team
>>
>>
>>
>> Request for reviewing my draft titled -
>>
>> Efficient Service-Carving in Evpn Multi-homed Networks.
>>
>> The same is submitted and available in the link below.
>>
>>
>> https://datatracker.ietf.org/doc/draft-kiran-bess-service-carving-evpn-multi-homing/
>>
>>
>>
>> Thanks in advance.
>>
>>
>> Regards
>>
>> Kiran
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: *Kiran KT* <kirank...@gmail.com>
>> Date: Sun, Aug 25, 2024 at 7:42 PM
>> Subject: Review request for draft - Efficient service carving in
>> Multi-homed Evpn networks
>> To: <bess@ietf.org>
>> Cc: Kiran KT <kirank...@gmail.com>
>>
>>
>>
>> Hello Team
>>
>>
>>
>> I have submitted a private draft titled -
>>
>> Efficient Service-Carving in Evpn Multi-homed Networks.
>>
>> The same is submitted and available in the link below.
>>
>>
>> https://datatracker.ietf.org/doc/draft-kiran-bess-service-carving-evpn-multi-homing/
>>
>> Request for review and comments.
>>
>> Thanks in advance.
>>
>>
>>
>> Regards
>>
>> Kiran
>>
>>
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
