Hi Bruno, Jorge, et al.,
Jorge,
> Among the co-authors we also discussed the possibility of defining two ECs:
> one for BW and one for a generalized-weight, so that the remote PE can catch
> if the multi-homed PEs were indeed using the same meaning of the weight.
> However, we thought it
Hi Neeraj,
Thanks for considering my comments.
Much better from my perspective. Thank you.
I have two comments on the changes:
- Regarding deployments
ยง4.1 allows two rather incompatible encodings/usages with no way to detect
which one is used: some PE could advertise the bandwidth in bytes,
Hi Bruno,
Thanks for your comments.
About the first point, we do have use cases where the bandwidth is not what we
want to encode in the EC but rather a generalized weight that is derived from
the link count, logical weight or simply a configured value. Among the
co-authors we also discussed
Hi Jorge,
Thanks for the feedback.
Regarding the first point, I can live with the current text. But I think I
would prefer that the text favour one option, and leave it to the
responsibility of the SP for others usages. E.g.
OLD:
EVPN Link Bandwidth Extended Community value field is to be
Bruno,
I had suggested:
"The value field in the link bandwidth EC is to be treated as a 6 octet
unsigned integer and it is the provider's responsibility to encode it
consistently across all of the PEs attached to a given ES. So, for example, if
the provider wanted the EC to represent
Bruno,
If you like we could say that the EC value field is an unsigned integer which
by default represents the attachment circuit bandwidth in units of 1 GBPS. (As
an aside, if six octet unsigned integer arithmetic is difficult, we could say
that the value field is a four octet unsigned
Hi John,
Personally, I would prefer that the text indicates the default/standardized
usage, such that by default, if all operators follow this, this just works.
Proposing no default and that everyone be free to pick his own unit seem to me
a path for domain1/AS1/VPN1 picks unit 1 and
John,
> It's *not* all egress PEs, it's only the multi-homed PEs attached to the same
> ES that need to be configured consistently
Agreed.
But step by step consistency becomes nice to have on all PEs: on a given PE,
you probably don't want to mix and match different units on a per ES basis. So
Bruno,
It's *not* all egress PEs, it's only the multi-homed PEs attached to the same
ES that need to be configured consistently. This is exactly the same
requirement that we have for Ethernet Tag in RFC 8484:
https://datatracker.ietf.org/doc/html/rfc8584#section-1.1.
Yours Irrespectively,
John,
My comment is limited to specifying the default unit which provides consistency
by default. I had proposed some text, but others word along this line works for
me.
Your below text goes beyond this and proposes to additionally change the unit
and the syntax. That's your proposal, not
Bruno,
The concern I have with bytes/sec is that given current and future link speeds,
it wastes a lot of bits describing link speeds that no longer exist.
Yours Irrespectively,
John
Juniper Business Use Only
From: bruno.decra...@orange.com
Sent: Thursday, May 6, 2021 10:46 AM
To: John E
Bruno,
I'm sorry, I was just proposing 1 GBS for purposes of discussion. I think 1
Mbit/s would be fine.
Yours Irrespectively,
John
Juniper Business Use Only
From: bruno.decra...@orange.com
Sent: Thursday, May 6, 2021 11:58 AM
To: John E Drake
Cc: slitkows.i...@gmail.com; bess@ietf.org;
John,
Those bits are transmitted in the community/BGP in all cases (whether
transmitted as 0 or as significant bits) and probably needs to be locally
stored in case the BGP routes needs to be re-advertised to another BGP peer.
So we are talking about integer computation...
I was just saying
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : MVPN and MSDP SA Interoperation
Authors : Zhaohui Zhang
Lenny Giuliano
Hi Qin,
Thank you so much for the review and comments. I have posted -06 revision.
Jeffrey
From: Qin Wu
Sent: Friday, April 30, 2021 11:59 AM
To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano
; ops-dir
Cc: bess ; draft-ietf-bess-mvpn-msdp-sa-interoperation.all
; last-call
Subject: RE: Opsdir
15 matches
Mail list logo
