[bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

slitkows.ietf
Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 


_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

bruno.decraene-2

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

Neeraj Malhotra

Hi Bruno,

Many thanks for the review comments. We have revised the draft addressing your comments. 

More inline.

Thanks,
Neeraj

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?


[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).
 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?


[NM]: clarified in section 4.
 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)


[NM]: done.
 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?


[NM]: I don't have this information. Perhaps someone else could comment.
 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

bruno.decraene-2

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [mailto:[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

Rabadan, Jorge (Nokia - US/Mountain View)

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 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 was easier/simpler to use a generalized value in a single EC sub-type, and add the sentence below.

 

The sentence can be modified/fixed. But the gist is that the multi-homed PEs may support multiple meanings for the weight (BW, link-count, etc), but at least one of those MUST be common across all PEs and the multi-homed routes must use it consistently. Would it be enough if we fix it?

 

About existing implementations, a new EVPN sub-type was defined only a couple of revisions ago, where, before, the existing non-transitive link BW EC was used, so there’s been some churn in the use of the EC anyway. I think it is important to get it as soon as possible, but get it right rather than finding gaps later once the document is done. But let us know your thoughts too.

 

Thank you.

Jorge

 

 

From: BESS <[hidden email]> on behalf of [hidden email] <[hidden email]>
Date: Thursday, May 6, 2021 at 10:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email] <[hidden email]>, [hidden email] <[hidden email]>
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [mailto:[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

bruno.decraene-2

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 treated

   as a 6 octet unsigned integer that may be set to:

 

   o  total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

   o  or a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other

      than link bandwidth.

 

   An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.  Procedures related to

   signaling and handling of this extended community defined in this

   document use "total bandwidth in bytes/sec" encoding as an example to

   illustrate its usage.

 

NEW:

   EVPN Link Bandwidth Extended Community value field is to be treated

   as a 6 octet unsigned integer representing total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

Note however that the load balancing algorithm defines in this document uses ratio of Link Bandwidths hence the operator may choose a different unit or use the community as

    a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other

      than link bandwidth. In such case, the operator MUST ensure consistent usage of the unit

across all PEs in an ethernet segment. This may involve multiple routing domains/Autonomous Systems.

 

 

But I leave this to you.

 

Thanks,

--Bruno

 

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[hidden email]]
Sent: Thursday, May 6, 2021 10:36 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 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 was easier/simpler to use a generalized value in a single EC sub-type, and add the sentence below.

 

The sentence can be modified/fixed. But the gist is that the multi-homed PEs may support multiple meanings for the weight (BW, link-count, etc), but at least one of those MUST be common across all PEs and the multi-homed routes must use it consistently. Would it be enough if we fix it?

 

About existing implementations, a new EVPN sub-type was defined only a couple of revisions ago, where, before, the existing non-transitive link BW EC was used, so there’s been some churn in the use of the EC anyway. I think it is important to get it as soon as possible, but get it right rather than finding gaps later once the document is done. But let us know your thoughts too.

 

Thank you.

Jorge

 

 

From: BESS <[hidden email]> on behalf of [hidden email] <[hidden email]>
Date: Thursday, May 6, 2021 at 10:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email] <[hidden email]>, [hidden email] <[hidden email]>
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John E Drake
In reply to this post by bruno.decraene-2

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

bruno.decraene-2

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [mailto:[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <bruno.decra
[hidden email]>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John E Drake

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

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 9:16 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]
>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

bruno.decraene-2

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 consistency per PE. Since an ES may be attached to different PEs, it’s easier to have consistency across PEs within a domain. Then you have multi domains scenarios, including a new domain been involved long after the original network design.

In the absence of global consistency, at some point when you have to merge PE/domains/VPNs the inconsistency becomes problematic and requires some special cases/handling.

Seems simpler to ensure consistency by default. At least to me.

 

We are not even discussing reducing the number of options, not to mention to one. We are only discussing to pick one per default so that we get interop by default.

This point may be moved to a deployment consideration section if you believe that this hurts the specification. But I feel that it may have impact on implementations e.g. one cli/yang model/documentation referring to bit/s while the other one referring to bytes/s… and voilà we are likely to have inconsistencies.

 

Regards,

--Bruno

 

From: John E Drake [mailto:[hidden email]]
Sent: Thursday, May 6, 2021 3:37 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 9:16 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]
>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John E Drake

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 integer that is right hand justified within the six octet value field.)

 

If a value other than attachment circuit bandwidth is being represented, it must be configured consistently on all of the PEs attached to a given ES.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:06 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 consistency per PE. Since an ES may be attached to different PEs, it’s easier to have consistency across PEs within a domain. Then you have multi domains scenarios, including a new domain been involved long after the original network design.

In the absence of global consistency, at some point when you have to merge PE/domains/VPNs the inconsistency becomes problematic and requires some special cases/handling.

Seems simpler to ensure consistency by default. At least to me.

 

We are not even discussing reducing the number of options, not to mention to one. We are only discussing to pick one per default so that we get interop by default.

This point may be moved to a deployment consideration section if you believe that this hurts the specification. But I feel that it may have impact on implementations e.g. one cli/yang model/documentation referring to bit/s while the other one referring to bytes/s… and voilà we are likely to have inconsistencies.

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 3:37 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 9:16 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]
>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

bruno.decraene-2

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 mine. I leave this to the authors/WG. But I’m a priori not fine with unsigned integer in units of 1 GBPS as it does not seem to work with links below 1GBPS. (I personally don’t see an issue with the encoding currently chosen in the draft but if authors/WG want to change, this also works for me)

 

Regards,

--Bruno

 

From: John E Drake [mailto:[hidden email]]
Sent: Thursday, May 6, 2021 4:23 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 integer that is right hand justified within the six octet value field.)

 

If a value other than attachment circuit bandwidth is being represented, it must be configured consistently on all of the PEs attached to a given ES.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:06 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 consistency per PE. Since an ES may be attached to different PEs, it’s easier to have consistency across PEs within a domain. Then you have multi domains scenarios, including a new domain been involved long after the original network design.

In the absence of global consistency, at some point when you have to merge PE/domains/VPNs the inconsistency becomes problematic and requires some special cases/handling.

Seems simpler to ensure consistency by default. At least to me.

 

We are not even discussing reducing the number of options, not to mention to one. We are only discussing to pick one per default so that we get interop by default.

This point may be moved to a deployment consideration section if you believe that this hurts the specification. But I feel that it may have impact on implementations e.g. one cli/yang model/documentation referring to bit/s while the other one referring to bytes/s… and voilà we are likely to have inconsistencies.

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 3:37 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 9:16 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]
>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John E Drake

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: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:46 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 mine. I leave this to the authors/WG. But I’m a priori not fine with unsigned integer in units of 1 GBPS as it does not seem to work with links below 1GBPS. (I personally don’t see an issue with the encoding currently chosen in the draft but if authors/WG want to change, this also works for me)

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 4:23 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 integer that is right hand justified within the six octet value field.)

 

If a value other than attachment circuit bandwidth is being represented, it must be configured consistently on all of the PEs attached to a given ES.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:06 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 consistency per PE. Since an ES may be attached to different PEs, it’s easier to have consistency across PEs within a domain. Then you have multi domains scenarios, including a new domain been involved long after the original network design.

In the absence of global consistency, at some point when you have to merge PE/domains/VPNs the inconsistency becomes problematic and requires some special cases/handling.

Seems simpler to ensure consistency by default. At least to me.

 

We are not even discussing reducing the number of options, not to mention to one. We are only discussing to pick one per default so that we get interop by default.

This point may be moved to a deployment consideration section if you believe that this hurts the specification. But I feel that it may have impact on implementations e.g. one cli/yang model/documentation referring to bit/s while the other one referring to bytes/s… and voilà we are likely to have inconsistencies.

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 3:37 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 9:16 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]
>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

bruno.decraene-2

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 that (access) link below 1GBPS still exists, at least in some region. If you change your proposal to a different offset (e.g. Mbit/s) that would better work for me and probably still address your point.

Again, I leave this encoding discussion between you and the authors.

 

Regards,

Bruno

 

 

From: John E Drake [mailto:[hidden email]]
Sent: Thursday, May 6, 2021 5:09 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:46 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 mine. I leave this to the authors/WG. But I’m a priori not fine with unsigned integer in units of 1 GBPS as it does not seem to work with links below 1GBPS. (I personally don’t see an issue with the encoding currently chosen in the draft but if authors/WG want to change, this also works for me)

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 4:23 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 integer that is right hand justified within the six octet value field.)

 

If a value other than attachment circuit bandwidth is being represented, it must be configured consistently on all of the PEs attached to a given ES.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:06 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 consistency per PE. Since an ES may be attached to different PEs, it’s easier to have consistency across PEs within a domain. Then you have multi domains scenarios, including a new domain been involved long after the original network design.

In the absence of global consistency, at some point when you have to merge PE/domains/VPNs the inconsistency becomes problematic and requires some special cases/handling.

Seems simpler to ensure consistency by default. At least to me.

 

We are not even discussing reducing the number of options, not to mention to one. We are only discussing to pick one per default so that we get interop by default.

This point may be moved to a deployment consideration section if you believe that this hurts the specification. But I feel that it may have impact on implementations e.g. one cli/yang model/documentation referring to bit/s while the other one referring to bytes/s… and voilà we are likely to have inconsistencies.

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 3:37 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 9:16 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]
>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John E Drake

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: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 11:58 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 that (access) link below 1GBPS still exists, at least in some region. If you change your proposal to a different offset (e.g. Mbit/s) that would better work for me and probably still address your point.

Again, I leave this encoding discussion between you and the authors.

 

Regards,

Bruno

 

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 5:09 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:46 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 mine. I leave this to the authors/WG. But I’m a priori not fine with unsigned integer in units of 1 GBPS as it does not seem to work with links below 1GBPS. (I personally don’t see an issue with the encoding currently chosen in the draft but if authors/WG want to change, this also works for me)

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 4:23 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 integer that is right hand justified within the six octet value field.)

 

If a value other than attachment circuit bandwidth is being represented, it must be configured consistently on all of the PEs attached to a given ES.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 10:06 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 consistency per PE. Since an ES may be attached to different PEs, it’s easier to have consistency across PEs within a domain. Then you have multi domains scenarios, including a new domain been involved long after the original network design.

In the absence of global consistency, at some point when you have to merge PE/domains/VPNs the inconsistency becomes problematic and requires some special cases/handling.

Seems simpler to ensure consistency by default. At least to me.

 

We are not even discussing reducing the number of options, not to mention to one. We are only discussing to pick one per default so that we get interop by default.

This point may be moved to a deployment consideration section if you believe that this hurts the specification. But I feel that it may have impact on implementations e.g. one cli/yang model/documentation referring to bit/s while the other one referring to bytes/s… and voilà we are likely to have inconsistencies.

 

Regards,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 3:37 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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

 

 

Juniper Business Use Only

From: [hidden email] <[hidden email]>
Sent: Thursday, May 6, 2021 9:16 AM
To: John E Drake <[hidden email]>
Cc: [hidden email]; [hidden email]; Neeraj Malhotra <[hidden email]>
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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 domain2/AS2/VPN2 picks unit 2. Then in case of merge, inter-domain/AS/VPN, we may ends up using inconsistent units.

 

> This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

I think that we all agree with this.

But this assumes and hence requires that all egress PEs use the same unit. Having a single unit (e.g., bytes/s) is a simple way to ensure this. If one want to state multiple options, stating the easy default and providing a warning for variations seems to increase the probability of consistency in various cases (including the one above e.g. network merges). IOW, to me the unit/semantic is part of the interoperability and hence standard. It’s only about encoding/syntax. e.g. my outdoor temperature is 30°. Does this sound hot or cold to you?

 

Thanks,

--Bruno

 

From: John E Drake [[hidden email]]
Sent: Thursday, May 6, 2021 2:54 PM
To: DECRAENE Bruno TGI/OLN <[hidden email]
>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 attachment circuit bandwidth, it should decide the units, e.g., 1 GBPS, and then encode the value field as a multiple of that unit.  

 

This ensures that when an ingress PE is doing weighted load balancing, in all cases it is doing simple integer arithmetic on values whose semantics are unknown to it.”

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 4:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

[External Email. Be cautious of content]

 

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

ietf-5
In reply to this post by bruno.decraene-2

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 was easier/simpler to use a generalized value in a single EC sub-type, and add the sentence below.

Have you considered reserving a byte in the value field to signal a weight type? Similar to how it is done with DF election framework (and allocate a few right away, e.g. 0 for physical link BW, 1 for link count, 2 for manually configured weight, ...). This would help not only with interop cases, but to prevent & diagnose potential configuration mistakes as well.

 

For interop reasons, I would support Bruno & argue that it makes sense to use "SHOULD" normative language at least for one way of calculation (e.g. BW).

 

A couple of minor comments on newly-introduced text in -09 and -10:

  1. Revision -10 introduced a curious change in section 5.2 “Remote PE Behavior”, replacing “1000 Mbps” with “1000 megabytes” in an example. It is not correct in the current form, since right above it there is an explicit statement that links are Gigabit Ethernet: "As an example, for a CE dual-homed to PE-1, PE-2, PE-3 via 2, 1, and 1 GE physical links respectively".

(keeping the Mbps units there would be appropriate, since this is a weight calculation, not a community encoding example)

  1. Section 4.1 “Usage of EVPN Link Bandwidth Extended Community”:

“An implementation may support one or more of the above ways of encoding the value." -> I would assume this should be "MUST support at least one", since every other possible option is included in bullet#2?

 

--

Sergey

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 5:46 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[hidden email]>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 treated

   as a 6 octet unsigned integer that may be set to:

 

   o  total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

   o  or a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other

      than link bandwidth.

 

   An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.  Procedures related to

   signaling and handling of this extended community defined in this

   document use "total bandwidth in bytes/sec" encoding as an example to

   illustrate its usage.

 

NEW:

   EVPN Link Bandwidth Extended Community value field is to be treated

   as a 6 octet unsigned integer representing total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

Note however that the load balancing algorithm defines in this document uses ratio of Link Bandwidths hence the operator may choose a different unit or use the community as

    a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other

      than link bandwidth. In such case, the operator MUST ensure consistent usage of the unit

across all PEs in an ethernet segment. This may involve multiple routing domains/Autonomous Systems.

 

 

But I leave this to you.

 

Thanks,

--Bruno

 

From: Rabadan, Jorge (Nokia - US/Mountain View) [[hidden email]]
Sent: Thursday, May 6, 2021 10:36 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 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 was easier/simpler to use a generalized value in a single EC sub-type, and add the sentence below.

 

The sentence can be modified/fixed. But the gist is that the multi-homed PEs may support multiple meanings for the weight (BW, link-count, etc), but at least one of those MUST be common across all PEs and the multi-homed routes must use it consistently. Would it be enough if we fix it?

 

About existing implementations, a new EVPN sub-type was defined only a couple of revisions ago, where, before, the existing non-transitive link BW EC was used, so there’s been some churn in the use of the EC anyway. I think it is important to get it as soon as possible, but get it right rather than finding gaps later once the document is done. But let us know your thoughts too.

 

Thank you.

Jorge

 

 

From: BESS <[hidden email]> on behalf of [hidden email] <[hidden email]>
Date: Thursday, May 6, 2021 at 10:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email] <[hidden email]>, [hidden email] <[hidden email]>
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

Neeraj Malhotra

Hi Sergey,

Thanks for the comments. We would like to avoid adding another code point within the value field, as every new encoding of the "weight" will require a new code point. Agree that we should specify the default units (for which the consensus on the thread appears to be Mbps), but would rather leave it to implementations to support any additional units such as number of links, configured weight, or anything else, than have a standardized code point for each unit. Please let me know if this sounds fine. I will fix the units in section 5.2, and the text in section 4.1 as suggested by you and Bruno.

Thanks,
Neeraj

On Thu, May 6, 2021 at 9:19 PM <[hidden email]> wrote:

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 was easier/simpler to use a generalized value in a single EC sub-type, and add the sentence below.

Have you considered reserving a byte in the value field to signal a weight type? Similar to how it is done with DF election framework (and allocate a few right away, e.g. 0 for physical link BW, 1 for link count, 2 for manually configured weight, ...). This would help not only with interop cases, but to prevent & diagnose potential configuration mistakes as well.

 

For interop reasons, I would support Bruno & argue that it makes sense to use "SHOULD" normative language at least for one way of calculation (e.g. BW).

 

A couple of minor comments on newly-introduced text in -09 and -10:

  1. Revision -10 introduced a curious change in section 5.2 “Remote PE Behavior”, replacing “1000 Mbps” with “1000 megabytes” in an example. It is not correct in the current form, since right above it there is an explicit statement that links are Gigabit Ethernet: "As an example, for a CE dual-homed to PE-1, PE-2, PE-3 via 2, 1, and 1 GE physical links respectively".

(keeping the Mbps units there would be appropriate, since this is a weight calculation, not a community encoding example)

  1. Section 4.1 “Usage of EVPN Link Bandwidth Extended Community”:

“An implementation may support one or more of the above ways of encoding the value." -> I would assume this should be "MUST support at least one", since every other possible option is included in bullet#2?

 

--

Sergey

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 5:46 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[hidden email]>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 treated

   as a 6 octet unsigned integer that may be set to:

 

   o  total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

   o  or a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other

      than link bandwidth.

 

   An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.  Procedures related to

   signaling and handling of this extended community defined in this

   document use "total bandwidth in bytes/sec" encoding as an example to

   illustrate its usage.

 

NEW:

   EVPN Link Bandwidth Extended Community value field is to be treated

   as a 6 octet unsigned integer representing total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

Note however that the load balancing algorithm defines in this document uses ratio of Link Bandwidths hence the operator may choose a different unit or use the community as

    a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other

      than link bandwidth. In such case, the operator MUST ensure consistent usage of the unit

across all PEs in an ethernet segment. This may involve multiple routing domains/Autonomous Systems.

 

 

But I leave this to you.

 

Thanks,

--Bruno

 

From: Rabadan, Jorge (Nokia - US/Mountain View) [[hidden email]]
Sent: Thursday, May 6, 2021 10:36 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 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 was easier/simpler to use a generalized value in a single EC sub-type, and add the sentence below.

 

The sentence can be modified/fixed. But the gist is that the multi-homed PEs may support multiple meanings for the weight (BW, link-count, etc), but at least one of those MUST be common across all PEs and the multi-homed routes must use it consistently. Would it be enough if we fix it?

 

About existing implementations, a new EVPN sub-type was defined only a couple of revisions ago, where, before, the existing non-transitive link BW EC was used, so there’s been some churn in the use of the EC anyway. I think it is important to get it as soon as possible, but get it right rather than finding gaps later once the document is done. But let us know your thoughts too.

 

Thank you.

Jorge

 

 

From: BESS <[hidden email]> on behalf of [hidden email] <[hidden email]>
Date: Thursday, May 6, 2021 at 10:04 AM
To: Neeraj Malhotra <[hidden email]>
Cc: [hidden email] <[hidden email]>, [hidden email] <[hidden email]>
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

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, while some other PE could advertise a general weight. I understand that both works, but to me there is a significant risk of issues over time or between domain/SP. I’d prefer that you only chose one in order to favour consistency in deployments and usage and I would prefer the real bandwidth (at least for consistency with the name of the community, but also because this is not subjective)  (And if a SP really wants to put an arbitrary value, I think he will figure out by himself, that it can do so).

If you disagree with the above, then I would have a comment on the two below sentences:

An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.

Logic dictates that the second sentence (MUST) can only be fulfilled if the first sentence mandates that all implementations MUST support both options, or one specifically defined.

 

- Regarding existing implementations:

previous version of the draft did not really specify the format of the EVPN EC. I had personally assumed that the format was similar to the draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in IEEE floating point format. Latest version of the draft defines it in unsigned integer. Integer looks good to me, but for an existing implementation this may be seen as an incompatible change very late in the process. Obviously, if there are no implementation, there is no issue. In which case, you could also express the bandwidth in unit of bit/s _if you_ wish to. (I have no preference). However given that the draft had indicated a codepoint, there seem to be a risk of existing implementations hence incompatible change. BTW the codepoint is squatted even though the registry is FCFS hence easy to request.

 

Thanks,

--Bruno

 

 

From: Neeraj Malhotra [[hidden email]]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

 

Hi Bruno,

 

Many thanks for the review comments. We have revised the draft addressing your comments. 

 

More inline.

 

Thanks,

Neeraj

 

On Mon, May 3, 2021 at 2:20 AM <[hidden email]> wrote:

Hi Stéphane, authors,

 

I have not followed the discussions on this document, but I’ll nonetheless raise one point  regarding the bandwidth community (better safe than sorry).

- why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory?

 

[NM]: There was a leftover reference to this in one of the sections that has been fixed now to use new EVPN EC. With this, reference to [BGP-LINK-BW] is purely informational (as was intended).

 

- A new EVPN Link Bandwidth extended community is defined, but I could not find its specification. I guess that this is the same format as [BGP-LINK-BW] but transitive. Could this be explicitly stated?

 

[NM]: clarified in section 4.

 

- [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per second. Could the unit of the new EVPN Link Bandwidth extended community be also clearly spelled out? Especially give the history on this (cf below). Also in order to avoid misleading the readers could the examples use the correct unit (vs bits per seconds as writen)

 

[NM]: done.

 

- 10 years ago or so, I had raised a similar point (distinction between bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1 major implementation had implemented and deployed “bytes per second” as per the spec, while another implementation had implemented and deployed “bits per second” which is the typical unit of link bandwidth. Given the deployments, none was willing to change its implementation as it would be a non-backward compatible change with themselves. What’s the status on this? Could we have an implementation status on this?

 

[NM]: I don't have this information. Perhaps someone else could comment.

 

 

Thanks

Regards,

--Bruno

 

 

From: BESS [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Monday, May 3, 2021 9:21 AM
To: [hidden email]
Subject: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

Hi WG,
 
 
 
We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
 
I'm opening a new short Working Group Last Call (to be closed on 5/10) to
get any last comments before moving to the next step.
However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
 
 
Feel free to send comments to the list before next Monday.
 
 
 
Thanks,
 
 
 
Stephane
 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
 
 
 
 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/bess
Reply | Threaded
Open this post in threaded view
|

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

ietf-5
Hi Neeraj,
thank you for the feedback.
 
I agree that allocating a new code point for every possible calculation method would be cumbersome.
How about a middle ground solution, with allocation of just a few values (even 2 would suffice: 1 for BW in whatever units we decide; the other "catch-all" generalized weight)?
This way operators will get at least basic visibility & cfg. error prevention mechanism in place (I have a preference towards explicit signaling from ops point of view; but would be glad to hear operators opinion on this one).
 
My concern with the current text is, while striving for maximum flexibility, we may end up in a situation where 2 implementations won't be able to interoperate with each other (e.g. vendor X decides to implement link BW as a metric, vendor Y decides to implement link count as a metric - since support for any method of weight calculation is completely optional). I believe we, as a technical community, should give guidance on implementing sensible defaults (i.e. "an implementation SHOULD support BW weight calculation method") where it makes sense.
 
-- 
Sergey
 
 
07.05.2021, 09:18, "Neeraj Malhotra" <[hidden email]>:
 
Hi Sergey,
 
Thanks for the comments. We would like to avoid adding another code point within the value field, as every new encoding of the "weight" will require a new code point. Agree that we should specify the default units (for which the consensus on the thread appears to be Mbps), but would rather leave it to implementations to support any additional units such as number of links, configured weight, or anything else, than have a standardized code point for each unit. Please let me know if this sounds fine. I will fix the units in section 5.2, and the text in section 4.1 as suggested by you and Bruno.
 
Thanks,
Neeraj
 
On Thu, May 6, 2021 at 9:19 PM <[hidden email]> wrote:

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 was easier/simpler to use a generalized value in a single EC sub-type, and add the sentence below.

Have you considered reserving a byte in the value field to signal a weight type? Similar to how it is done with DF election framework (and allocate a few right away, e.g. 0 for physical link BW, 1 for link count, 2 for manually configured weight, ...). This would help not only with interop cases, but to prevent & diagnose potential configuration mistakes as well.

 

For interop reasons, I would support Bruno & argue that it makes sense to use "SHOULD" normative language at least for one way of calculation (e.g. BW).

 

A couple of minor comments on newly-introduced text in -09 and -10:

  1. Revision -10 introduced a curious change in section 5.2 “Remote PE Behavior”, replacing “1000 Mbps” with “1000 megabytes” in an example. It is not correct in the current form, since right above it there is an explicit statement that links are Gigabit Ethernet: "As an example, for a CE dual-homed to PE-1, PE-2, PE-3 via 2, 1, and 1 GE physical links respectively".

(keeping the Mbps units there would be appropriate, since this is a weight calculation, not a community encoding example)

  1. Section 4.1 “Usage of EVPN Link Bandwidth Extended Community”:

“An implementation may support one or more of the above ways of encoding the value." -> I would assume this should be "MUST support at least one", since every other possible option is included in bullet#2?

 

--

Sergey

From: BESS <[hidden email]> On Behalf Of [hidden email]
Sent: Thursday, May 6, 2021 5:46 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[hidden email]>; Neeraj Malhotra <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

 

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 treated

   as a 6 octet unsigned integer that may be set to:

 

   o  total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

   o  or a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other

      than link bandwidth.

 

   An implementation may support one or more of the above ways of

   encoding the value.  Operator MUST ensure consistent encoding of this

   value across all PEs in an ethernet segment.  Procedures related to

   signaling and handling of this extended community defined in this

   document use "total bandwidth in bytes/sec" encoding as an example to

   illustrate its usage.

 

NEW:

   EVPN Link Bandwidth Extended Community value field is to be treated

   as a 6 octet unsigned integer representing total bandwidth of PE's all physical links in an ethernet segment,

      expressed in bytes/sec.

 

Note however that the load balancing algorithm defines in this document uses ratio of Link Bandwidths hence the operator may choose a different unit or use the community as

    a generalized weight that may be set to link count, locally

      configured weight, or a value computed based on an attribute other