Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
Yes, I agree.
Thanks.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Wednesday, February 7, 2018 at 11:52 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>,
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi,
> In that case, two PEs in the same ES supporting type=255 should rely on
local policy to decide what to.
If type=255 is used, the local policy should be applied and it becomes the
job of the operator to ensure that the policy is the same everywhere.
> And two PEs in the same ES supporting different types should revert back
to type=0 (RFC7432).
Yes that sounds reasonable as this is the only behavior in common.
Brgds,
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 07, 2018 09:40
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
When a new type comes up, we normally encourage people to publish a draft
and register a temporary type with IANA, so that others can interop. Having
said that, I think your idea is good and we could reserve type=255 for
vendor-specific or experimental purposes, so that people can use it prior to
writing a draft and request a normal type.
In that case, two PEs in the same ES supporting type=255 should rely on
local policy to decide what to. And two PEs in the same ES supporting different
types should revert back to type=0 (RFC7432).
Thank you.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Wednesday, February 7, 2018 at 9:17 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>,
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Jorge,
This perfectly fills my comment.
Speaking as doc shepherd and WG member, I think it could make sense to
have a vendor specific DF election type allocated. This would allow a vendor to
develop a specific algorithm to address a niche use case, not supported by
other vendors.
What do you think ?
Thanks,
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 07, 2018 07:38
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
We'll modify the text based on your comments below.
Also for the benefit of the entire WG, based on Stephane's (and others)
feedback, we will add an indication of the support of the ac-df draft in the DF
Election extended community. The DF Election extended community is used by a
number of drafts, so it is important that the WG is aware of this. The proposed
encoding of the DF Election extended community is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(0x06)| DF Type | Bitmap|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0 |DF Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following fields are defined as follows:
o DF Type can have the following values already used in some drafts:
- Type 0 - Default, mod based DF election as per RFC7432.
- Type 1 - HRW algorithm as per [DF Election draft]
- Type 2 - Preference algorithm [Preference draft]
- Type 3 - BW DF Election [BW DF election draft]
o Bitmap field defines 'capabilities' that may be supported with
multiple types. Some examples already used in some drafts:
·Bit 24 – DP (don’t preempt – Pref draft)
·Bit 25 – AC-influenced Election (ac-df draft)
·Bit 26 – handshake (handshake draft)
o The DF Type determines if the reserved fields are used or not. F
Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi, > In that case, two PEs in the same ES supporting type=255 should rely on local > policy to decide what to. If type=255 is used, the local policy should be applied and it becomes the job of the operator to ensure that the policy is the same everywhere. > And two PEs in the same ES supporting different types should revert back to > type=0 (RFC7432). Yes that sounds reasonable as this is the only behavior in common. Brgds, -Original Message- From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com] Sent: Wednesday, February 07, 2018 09:40 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-ac-df.auth...@ietf.org Cc: bess@ietf.org Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df Hi Stephane, When a new type comes up, we normally encourage people to publish a draft and register a temporary type with IANA, so that others can interop. Having said that, I think your idea is good and we could reserve type=255 for vendor-specific or experimental purposes, so that people can use it prior to writing a draft and request a normal type. In that case, two PEs in the same ES supporting type=255 should rely on local policy to decide what to. And two PEs in the same ES supporting different types should revert back to type=0 (RFC7432). Thank you. Jorge -Original Message- From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com> Date: Wednesday, February 7, 2018 at 9:17 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, "draft-ietf-bess-evpn-ac-df.auth...@ietf.org" <draft-ietf-bess-evpn-ac-df.auth...@ietf.org> Cc: "bess@ietf.org" <bess@ietf.org> Subject: RE: Shepherd's review of draft-ietf-bess-evpn-ac-df Hi Jorge, This perfectly fills my comment. Speaking as doc shepherd and WG member, I think it could make sense to have a vendor specific DF election type allocated. This would allow a vendor to develop a specific algorithm to address a niche use case, not supported by other vendors. What do you think ? Thanks, -Original Message- From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com] Sent: Wednesday, February 07, 2018 07:38 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-ac-df.auth...@ietf.org Cc: bess@ietf.org Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df Hi Stephane, We'll modify the text based on your comments below. Also for the benefit of the entire WG, based on Stephane's (and others) feedback, we will add an indication of the support of the ac-df draft in the DF Election extended community. The DF Election extended community is used by a number of drafts, so it is important that the WG is aware of this. The proposed encoding of the DF Election extended community is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type(0x06)| DF Type | Bitmap| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved = 0 |DF Preference (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the following fields are defined as follows: o DF Type can have the following values already used in some drafts: - Type 0 - Default, mod based DF election as per RFC7432. - Type 1 - HRW algorithm as per [DF Election draft] - Type 2 - Preference algorithm [Preference draft] - Type 3 - BW DF Election [BW DF election draft] o Bitmap field defines 'capabilities' that may be supported with multiple types. Some examples already used in some drafts: ·Bit 24 – DP (don’t preempt – Pref draft) ·Bit 25 – AC-influenced Election (ac-df draft) ·Bit 26 – handshake (handshake draft) o The DF Type determines if the reserved fields are used or not. For example, if DF type=2, the last 2 octets will encode the preference value used in the preference draft. The DF Election extended community will be defined in one of the drafts (TBD) without defining the values above or the DF Preference. This draft will set up the IANA registry for DF Types and Bitmap. Then each individual draft will request IANA its own type or bit in the bitmap, and will specify if the new type or capability can be supported with other types. Please let us know if you have any feedback/questions. Thank you. Jorge -Original Message- From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com> Date: Wednesday, January 31, 2018 at 9:39 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" <j
Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
When a new type comes up, we normally encourage people to publish a draft and
register a temporary type with IANA, so that others can interop. Having said
that, I think your idea is good and we could reserve type=255 for
vendor-specific or experimental purposes, so that people can use it prior to
writing a draft and request a normal type.
In that case, two PEs in the same ES supporting type=255 should rely on local
policy to decide what to. And two PEs in the same ES supporting different types
should revert back to type=0 (RFC7432).
Thank you.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Wednesday, February 7, 2018 at 9:17 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>,
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Jorge,
This perfectly fills my comment.
Speaking as doc shepherd and WG member, I think it could make sense to have
a vendor specific DF election type allocated. This would allow a vendor to
develop a specific algorithm to address a niche use case, not supported by
other vendors.
What do you think ?
Thanks,
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 07, 2018 07:38
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
We'll modify the text based on your comments below.
Also for the benefit of the entire WG, based on Stephane's (and others)
feedback, we will add an indication of the support of the ac-df draft in the DF
Election extended community. The DF Election extended community is used by a
number of drafts, so it is important that the WG is aware of this. The proposed
encoding of the DF Election extended community is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(0x06)| DF Type | Bitmap|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0 |DF Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following fields are defined as follows:
o DF Type can have the following values already used in some drafts:
- Type 0 - Default, mod based DF election as per RFC7432.
- Type 1 - HRW algorithm as per [DF Election draft]
- Type 2 - Preference algorithm [Preference draft]
- Type 3 - BW DF Election [BW DF election draft]
o Bitmap field defines 'capabilities' that may be supported with multiple
types. Some examples already used in some drafts:
·Bit 24 – DP (don’t preempt – Pref draft)
·Bit 25 – AC-influenced Election (ac-df draft)
·Bit 26 – handshake (handshake draft)
o The DF Type determines if the reserved fields are used or not. For
example, if DF type=2, the last 2 octets will encode the preference value used
in the preference draft.
The DF Election extended community will be defined in one of the drafts
(TBD) without defining the values above or the DF Preference. This draft will
set up the IANA registry for DF Types and Bitmap. Then each individual draft
will request IANA its own type or bit in the bitmap, and will specify if the
new type or capability can be supported with other types.
Please let us know if you have any feedback/questions.
Thank you.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Wednesday, January 31, 2018 at 9:39 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>,
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Jorge,
Thanks for your answers.
Pls find more inline [SLI2]
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Tuesday, January 30, 2018 16:20
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi
Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Jorge,
This perfectly fills my comment.
Speaking as doc shepherd and WG member, I think it could make sense to have a
vendor specific DF election type allocated. This would allow a vendor to
develop a specific algorithm to address a niche use case, not supported by
other vendors.
What do you think ?
Thanks,
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 07, 2018 07:38
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
We'll modify the text based on your comments below.
Also for the benefit of the entire WG, based on Stephane's (and others)
feedback, we will add an indication of the support of the ac-df draft in the DF
Election extended community. The DF Election extended community is used by a
number of drafts, so it is important that the WG is aware of this. The proposed
encoding of the DF Election extended community is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(0x06)| DF Type | Bitmap|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0 |DF Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following fields are defined as follows:
o DF Type can have the following values already used in some drafts:
- Type 0 - Default, mod based DF election as per RFC7432.
- Type 1 - HRW algorithm as per [DF Election draft]
- Type 2 - Preference algorithm [Preference draft]
- Type 3 - BW DF Election [BW DF election draft]
o Bitmap field defines 'capabilities' that may be supported with multiple
types. Some examples already used in some drafts:
·Bit 24 – DP (don’t preempt – Pref draft)
·Bit 25 – AC-influenced Election (ac-df draft)
·Bit 26 – handshake (handshake draft)
o The DF Type determines if the reserved fields are used or not. For example,
if DF type=2, the last 2 octets will encode the preference value used in the
preference draft.
The DF Election extended community will be defined in one of the drafts (TBD)
without defining the values above or the DF Preference. This draft will set up
the IANA registry for DF Types and Bitmap. Then each individual draft will
request IANA its own type or bit in the bitmap, and will specify if the new
type or capability can be supported with other types.
Please let us know if you have any feedback/questions.
Thank you.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Wednesday, January 31, 2018 at 9:39 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>,
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Jorge,
Thanks for your answers.
Pls find more inline [SLI2]
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Tuesday, January 30, 2018 16:20
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
Thank you for your review.
Please see in-line and let me know what you think.
Thanks.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Tuesday, January 30, 2018 at 10:35 AM
To: "draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Shepherd's review of draft-ietf-bess-evpn-ac-df
Resent-From: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <kiran.naga...@nokia.com>,
<senthil.sathap...@nokia.com>, <vinod.pra...@nokia.com>, <h...@ciena.com>,
<w...@juniper.net>
Resent-Date: Tuesday, January 30, 2018 at 10:35 AM
Hi,
As shepherd of this document, please find below my comments.
IMO, this is a very useful proposal. The document is quite easy to
understand with a good illustrated example.
[JORGE] that's good, thanks.
Overall comments:
- I would encourage to have an acronym section containing all
abbreviations and the associated expansion. That could be a good best practice.
[JORGE] ok, done.
- I'm wondering why this docume
Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
We'll modify the text based on your comments below.
Also for the benefit of the entire WG, based on Stephane's (and others)
feedback, we will add an indication of the support of the ac-df draft in the DF
Election extended community. The DF Election extended community is used by a
number of drafts, so it is important that the WG is aware of this. The proposed
encoding of the DF Election extended community is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(0x06)| DF Type | Bitmap|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0 |DF Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following fields are defined as follows:
o DF Type can have the following values already used in some drafts:
- Type 0 - Default, mod based DF election as per RFC7432.
- Type 1 - HRW algorithm as per [DF Election draft]
- Type 2 - Preference algorithm [Preference draft]
- Type 3 - BW DF Election [BW DF election draft]
o Bitmap field defines 'capabilities' that may be supported with multiple
types. Some examples already used in some drafts:
·Bit 24 – DP (don’t preempt – Pref draft)
·Bit 25 – AC-influenced Election (ac-df draft)
·Bit 26 – handshake (handshake draft)
o The DF Type determines if the reserved fields are used or not. For example,
if DF type=2, the last 2 octets will encode the preference value used in the
preference draft.
The DF Election extended community will be defined in one of the drafts (TBD)
without defining the values above or the DF Preference. This draft will set up
the IANA registry for DF Types and Bitmap. Then each individual draft will
request IANA its own type or bit in the bitmap, and will specify if the new
type or capability can be supported with other types.
Please let us know if you have any feedback/questions.
Thank you.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Wednesday, January 31, 2018 at 9:39 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>,
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Jorge,
Thanks for your answers.
Pls find more inline [SLI2]
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Tuesday, January 30, 2018 16:20
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane,
Thank you for your review.
Please see in-line and let me know what you think.
Thanks.
Jorge
-Original Message-
From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Tuesday, January 30, 2018 at 10:35 AM
To: "draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
<draft-ietf-bess-evpn-ac-df.auth...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Shepherd's review of draft-ietf-bess-evpn-ac-df
Resent-From: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <kiran.naga...@nokia.com>,
<senthil.sathap...@nokia.com>, <vinod.pra...@nokia.com>, <h...@ciena.com>,
<w...@juniper.net>
Resent-Date: Tuesday, January 30, 2018 at 10:35 AM
Hi,
As shepherd of this document, please find below my comments.
IMO, this is a very useful proposal. The document is quite easy to
understand with a good illustrated example.
[JORGE] that's good, thanks.
Overall comments:
- I would encourage to have an acronym section containing all
abbreviations and the associated expansion. That could be a good best practice.
[JORGE] ok, done.
- I'm wondering why this document intended status is Informational. It
looks to fill a major (IMO) miss from the basic specification and I would be
happy to see it as a standard track document. Even if there is no protocol
extension involved, I think that standard track could make sense. Was this
already discussed ?
[JORGE] the reasons why the authors thought of Informational were because
a) it does not define any protocol extension and b) it is backwards compatible
with RFC7432, in the sense that a PE supporting this document and a PE
supporting RFC7432 could be put in the same Ethernet Segment and it would all
work (no loops or
Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Jorge, Thanks for your answers. Pls find more inline [SLI2] -Original Message- From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com] Sent: Tuesday, January 30, 2018 16:20 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-ac-df.auth...@ietf.org Cc: bess@ietf.org Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df Hi Stephane, Thank you for your review. Please see in-line and let me know what you think. Thanks. Jorge -Original Message- From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com> Date: Tuesday, January 30, 2018 at 10:35 AM To: "draft-ietf-bess-evpn-ac-df.auth...@ietf.org" <draft-ietf-bess-evpn-ac-df.auth...@ietf.org> Cc: "bess@ietf.org" <bess@ietf.org> Subject: Shepherd's review of draft-ietf-bess-evpn-ac-df Resent-From: <alias-boun...@ietf.org> Resent-To: <jorge.raba...@nokia.com>, <kiran.naga...@nokia.com>, <senthil.sathap...@nokia.com>, <vinod.pra...@nokia.com>, <h...@ciena.com>, <w...@juniper.net> Resent-Date: Tuesday, January 30, 2018 at 10:35 AM Hi, As shepherd of this document, please find below my comments. IMO, this is a very useful proposal. The document is quite easy to understand with a good illustrated example. [JORGE] that's good, thanks. Overall comments: - I would encourage to have an acronym section containing all abbreviations and the associated expansion. That could be a good best practice. [JORGE] ok, done. - I'm wondering why this document intended status is Informational. It looks to fill a major (IMO) miss from the basic specification and I would be happy to see it as a standard track document. Even if there is no protocol extension involved, I think that standard track could make sense. Was this already discussed ? [JORGE] the reasons why the authors thought of Informational were because a) it does not define any protocol extension and b) it is backwards compatible with RFC7432, in the sense that a PE supporting this document and a PE supporting RFC7432 could be put in the same Ethernet Segment and it would all work (no loops or packet duplication). That may not necessarily be the case with more than 2 PEs. Nevertheless the document does not recommend to do it in any case. I am personally happy to change it to Standards Track if the rest of the co-authors and the WG don't have any issues with it. - I'm not sure that we can say that this procedure is backward compatible. I agree that there is no protocol extension involved but as it is mentioned, we cannot mix PEs running the new procedure and PE running the old procedure. This must be ensured by the operator. Wouldn't it be better to add a flag/attribute to announce that a PE is capable to run this procedure ? Thus, when PEs run the svc carving algo, if they know that all the PEs are capable of this procedure, and they can all run it automatically. If there is one or more PE in the set that is not capable, they fallback to the regular procedure. [JORGE] As discussed above, we wanted to make it backwards compatible in a simple case. E.g. say PE1 and PE2 are in the same ES. PE1 supports this document and PE2 does not. In this case, link/node failures are covered by the baseline RFC7432. Logical AC failures don't change the RFC7432 overall behavior, for instance: a) a logical AC failure on PE1, will not change the DF, just like in RFC7432. b) a logical AC failure on PE2 makes PE1 take over, but, since PE2 can't forward traffic anyway, there are no loops/duplication and everything works. [SLI2] Being backward compatible on a simple case is IMO not enough to declare the solution as backward compatible. As you mentioned if more than two PEs are involved, we can fall into issues and human care are required. I don't consider this as backward compatible. - I would be in favor of having of deployment considerations section that deals with the backward compatibility and how to deploy the solution. [JORGE] We can add the section and the above example to clarify the "backwards compatibility" concept. [SLI2] That's good thanks. We just need to agree on the content :) - There are too much authors in the Author list. Would it be possible to reduce it ? Problem statement: "an ES route withdrawn will make...". [SLI] I have a doubt here, would it be "and ES route withdrawal will make" or "a withdrawn ES route" ? [JORGE] fixed to "an ES route withdrawal". Thx. Section 2.1 " After running the service-carving DF election algorithm" [SLI] Could you mention that you refer to the existing algorithm from RFC7432 ? [JORGE] done. Thanks. Section 2.2/2.3: - Would it be possible to collapse the two cases in a single procedure update ? - I do not like to mix exa
Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi Stephane, Thank you for your review. Please see in-line and let me know what you think. Thanks. Jorge -Original Message- From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com> Date: Tuesday, January 30, 2018 at 10:35 AM To: "draft-ietf-bess-evpn-ac-df.auth...@ietf.org" <draft-ietf-bess-evpn-ac-df.auth...@ietf.org> Cc: "bess@ietf.org" <bess@ietf.org> Subject: Shepherd's review of draft-ietf-bess-evpn-ac-df Resent-From: <alias-boun...@ietf.org> Resent-To: <jorge.raba...@nokia.com>, <kiran.naga...@nokia.com>, <senthil.sathap...@nokia.com>, <vinod.pra...@nokia.com>, <h...@ciena.com>, <w...@juniper.net> Resent-Date: Tuesday, January 30, 2018 at 10:35 AM Hi, As shepherd of this document, please find below my comments. IMO, this is a very useful proposal. The document is quite easy to understand with a good illustrated example. [JORGE] that's good, thanks. Overall comments: - I would encourage to have an acronym section containing all abbreviations and the associated expansion. That could be a good best practice. [JORGE] ok, done. - I'm wondering why this document intended status is Informational. It looks to fill a major (IMO) miss from the basic specification and I would be happy to see it as a standard track document. Even if there is no protocol extension involved, I think that standard track could make sense. Was this already discussed ? [JORGE] the reasons why the authors thought of Informational were because a) it does not define any protocol extension and b) it is backwards compatible with RFC7432, in the sense that a PE supporting this document and a PE supporting RFC7432 could be put in the same Ethernet Segment and it would all work (no loops or packet duplication). That may not necessarily be the case with more than 2 PEs. Nevertheless the document does not recommend to do it in any case. I am personally happy to change it to Standards Track if the rest of the co-authors and the WG don't have any issues with it. - I'm not sure that we can say that this procedure is backward compatible. I agree that there is no protocol extension involved but as it is mentioned, we cannot mix PEs running the new procedure and PE running the old procedure. This must be ensured by the operator. Wouldn't it be better to add a flag/attribute to announce that a PE is capable to run this procedure ? Thus, when PEs run the svc carving algo, if they know that all the PEs are capable of this procedure, and they can all run it automatically. If there is one or more PE in the set that is not capable, they fallback to the regular procedure. [JORGE] As discussed above, we wanted to make it backwards compatible in a simple case. E.g. say PE1 and PE2 are in the same ES. PE1 supports this document and PE2 does not. In this case, link/node failures are covered by the baseline RFC7432. Logical AC failures don't change the RFC7432 overall behavior, for instance: a) a logical AC failure on PE1, will not change the DF, just like in RFC7432. b) a logical AC failure on PE2 makes PE1 take over, but, since PE2 can't forward traffic anyway, there are no loops/duplication and everything works. - I would be in favor of having of deployment considerations section that deals with the backward compatibility and how to deploy the solution. [JORGE] We can add the section and the above example to clarify the "backwards compatibility" concept. - There are too much authors in the Author list. Would it be possible to reduce it ? Problem statement: "an ES route withdrawn will make...". [SLI] I have a doubt here, would it be "and ES route withdrawal will make" or "a withdrawn ES route" ? [JORGE] fixed to "an ES route withdrawal". Thx. Section 2.1 " After running the service-carving DF election algorithm" [SLI] Could you mention that you refer to the existing algorithm from RFC7432 ? [JORGE] done. Thanks. Section 2.2/2.3: - Would it be possible to collapse the two cases in a single procedure update ? - I do not like to mix examples with a procedure update description. I would rather be in favor of focusing on what is changing compared to RFC7432. For instance, "The step 3 is changed as follows:". Keeping the example is really good, so after describing the procedure, it makes sense to run it through the example. [JORGE] good point. I changed the text as follows: "For the specific case of VLAN-aware bundle services, the DF election will be influenced by the update/withdraw of "any" of the Ethernet A- D per EVI routes in the <ESI,EVI>. Step 5 and 6 in section 3.2 are therefore modified as follows: 5. When electing the DF for a given EVI, a PE will not be considered candidate
Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi again, There is one point that I have missed. Section 4 uses an old version of the requirement language. Please use the latest one: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. -Original Message- From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Tuesday, January 30, 2018 10:35 To: draft-ietf-bess-evpn-ac-df.auth...@ietf.org Cc: bess@ietf.org Subject: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df Hi, As shepherd of this document, please find below my comments. IMO, this is a very useful proposal. The document is quite easy to understand with a good illustrated example. Overall comments: - I would encourage to have an acronym section containing all abbreviations and the associated expansion. That could be a good best practice. - I'm wondering why this document intended status is Informational. It looks to fill a major (IMO) miss from the basic specification and I would be happy to see it as a standard track document. Even if there is no protocol extension involved, I think that standard track could make sense. Was this already discussed ? - I'm not sure that we can say that this procedure is backward compatible. I agree that there is no protocol extension involved but as it is mentioned, we cannot mix PEs running the new procedure and PE running the old procedure. This must be ensured by the operator. Wouldn't it be better to add a flag/attribute to announce that a PE is capable to run this procedure ? Thus, when PEs run the svc carving algo, if they know that all the PEs are capable of this procedure, and they can all run it automatically. If there is one or more PE in the set that is not capable, they fallback to the regular procedure. - I would be in favor of having of deployment considerations section that deals with the backward compatibility and how to deploy the solution. - There are too much authors in the Author list. Would it be possible to reduce it ? Problem statement: "an ES route withdrawn will make...". [SLI] I have a doubt here, would it be "and ES route withdrawal will make" or "a withdrawn ES route" ? Section 2.1 " After running the service-carving DF election algorithm" [SLI] Could you mention that you refer to the existing algorithm from RFC7432 ? Section 2.2/2.3: - Would it be possible to collapse the two cases in a single procedure update ? - I do not like to mix examples with a procedure update description. I would rather be in favor of focusing on what is changing compared to RFC7432. For instance, "The step 3 is changed as follows:". Keeping the example is really good, so after describing the procedure, it makes sense to run it through the example. Brgds, Stephane Litkowski _ 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 BESS@ietf.org 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; t
[bess] Shepherd's review of draft-ietf-bess-evpn-ac-df
Hi, As shepherd of this document, please find below my comments. IMO, this is a very useful proposal. The document is quite easy to understand with a good illustrated example. Overall comments: - I would encourage to have an acronym section containing all abbreviations and the associated expansion. That could be a good best practice. - I'm wondering why this document intended status is Informational. It looks to fill a major (IMO) miss from the basic specification and I would be happy to see it as a standard track document. Even if there is no protocol extension involved, I think that standard track could make sense. Was this already discussed ? - I'm not sure that we can say that this procedure is backward compatible. I agree that there is no protocol extension involved but as it is mentioned, we cannot mix PEs running the new procedure and PE running the old procedure. This must be ensured by the operator. Wouldn't it be better to add a flag/attribute to announce that a PE is capable to run this procedure ? Thus, when PEs run the svc carving algo, if they know that all the PEs are capable of this procedure, and they can all run it automatically. If there is one or more PE in the set that is not capable, they fallback to the regular procedure. - I would be in favor of having of deployment considerations section that deals with the backward compatibility and how to deploy the solution. - There are too much authors in the Author list. Would it be possible to reduce it ? Problem statement: "an ES route withdrawn will make...". [SLI] I have a doubt here, would it be "and ES route withdrawal will make" or "a withdrawn ES route" ? Section 2.1 " After running the service-carving DF election algorithm" [SLI] Could you mention that you refer to the existing algorithm from RFC7432 ? Section 2.2/2.3: - Would it be possible to collapse the two cases in a single procedure update ? - I do not like to mix examples with a procedure update description. I would rather be in favor of focusing on what is changing compared to RFC7432. For instance, "The step 3 is changed as follows:". Keeping the example is really good, so after describing the procedure, it makes sense to run it through the example. Brgds, Stephane Litkowski _ 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
