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 until "all" the Ethernet A-D per EVI routes for the
<ESI,EVI> have been received from that PE. In other words, all the
ACs on the <ESI,EVI> for a given PE must be UP so that the PE is
considered as candidate for a given EVI.
6. Once the PEs with missing Ethernet A-D per EVI routes for a given
EVI have been eliminated from the candidate list, the DF Election
can be applied for the remaining N candidates.
For example, assuming three bridge tables in PE-1 for the same MAC-
VRF (each one associated to a different Ethernet Tag), PE-1 will
advertise three Ethernet A-D per EVI routes for <ESI12,EVI1>. Each of
the three routes will indicate the status of each AC in <ESI12,EVI1>.
PE-1 will be considered as a valid candidate PE for DF election as
long as the three routes are active. If PE-1 withdraws one or more of
the Ethernet A-D per EVI routes for <ESI12,EVI1>, the PEs in ESI12
will not consider PE-1 as a suitable DF candidate for <ESI12,EVI1>."
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
