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:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, January 30, 2018 10:35
To: [email protected]
Cc: [email protected]
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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
