Hi Les,
From my perspective, it’s not about “making it easier to use/deploy”, it’s
about “not breaking existing networks” (and even not bothering the ones which
didn’t ask for it).
(Although “making it easier to use” may be relevant for people who want to use
it, that’s not really my point, quite the contrary.)
--Bruno
From: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Sent: Wednesday, September 25, 2024 4:29 PM
To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>
Cc: Yingzhen Qu <yingzhen.i...@gmail.com>; lsr <lsr@ietf.org>; lsr-chairs
<lsr-cha...@ietf.org>; Tony Li <tony...@tony.li>
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 -
7/15/2024)
Bruno –
In my mind there is a difference between defining what is necessary to
guarantee interoperability and defining what makes things easier to use (or -
if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to
want them to be treated the same. I don’t agree with this – not least because
“easy to use” is a very subjective criteria. People may legitimately have very
different opinions on this.
That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol
advertisements which deviate from the expected content in some way – and it
does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1
modified to use MUST in reporting alarms:
“Implementations which support disablement of MP-TLVs MUST report
alarms under the following conditions…”
We have not, however, modified the language in the previous paragraph i.e.,
RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.
These are all the modifications the authors are prepared to make in response to
your comments.
Thanx again for the good discussion.
WG chairs – please let us know the status of WG last call as no further updates
to the draft are planned.
Les
From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Sent: Tuesday, September 24, 2024 5:53 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; lsr
<lsr@ietf.org<mailto:lsr@ietf.org>>; lsr-chairs
<lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>; Tony Li
<tony...@tony.li<mailto:tony...@tony.li>>
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 -
7/15/2024)
Les,
Thanks for the summary and for your effort.
Please see inline [Bruno]
From: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Sent: Tuesday, September 24, 2024 7:36 AM
To: DECRAENE Bruno INNOV/NET
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>; Tony Li
<tony...@tony.li<mailto:tony...@tony.li>>
Cc: Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; lsr
<lsr@ietf.org<mailto:lsr@ietf.org>>; lsr-chairs
<lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 -
7/15/2024)
Folks –
I appreciate the good discussion that went on over the last couple weeks.
There are three potential textual changes being considered:
Section 4.1
"The set of link identifiers SHOULD be identical in all TLVs which are part of
the MP-TLV set."
Possibly changing "SHOULD" to MUST".
Section 7.1
"It is RECOMMENDED that implementations which support the sending of MP-TLVs
provide configuration controls to enable/disable generation of MP-TLVs. "
Possibly changing RECOMMENDED to REQUIRED
Section 7
"Providing appropriate controls to enable/disable the sending of MP-TLVs as
discussed in Section 7.1 is essential to avoid interoperability issues."
Changing "essential" to "important"
Note: This is a consistency issue - if we do NOT use REQUIRED in Section 7.1
then it would be better NOT to use "essential" in Section 7.
[Bruno] I agree on the above summary.
DISCUSSION
Regarding Section 7/7.1
The argument is being made that using “REQUIRED/essential” reduces the
potential for interoperability problems. This assumes that some vendors who
might otherwise NOT implement the recommended practices would be more likely
to do so if normative language were used. This in turn presumes that the
chance of interoperability problems would be reduced as a result.
I am sympathetic to the goal. Many of us have had real world
experiences with interoperability issues and they are costly.
But I believe mandating aspects of an implementation which are unenforceable
and undetectable is not guaranteed to reduce interoperability issues.
The incidence of interoperability issues is most effectively reduced by
robustness in implementations. As Tony Li has stated:
"You do not make the network safer by mandate.
[Bruno] That is incorrect.
E.g. with regards to road safety, one can mandate safety belts, air bags,
traffic lights with mandating a stop when red, School bus traffic stop laws …
and this make the world safer. At least for the more fragile road users. Sure,
one could argue that buying a tank is the way for being safer… at least for
himself.
With regards to networks, RC7606 defines (or “mandates” if you want) new error
handling and this makes the network safer.
You make it safer by writing more forgiving code."
What is REQUIRED in a protocol specification are normative statements about
what is sent on the wire.
[Bruno] We are discussing what to send on the wire and when.
But asserting that there is "one correct way" for
an implementation to support enablement/disablement is not appropriate –
[Bruno] That is not what we are discussing. Please re-read your above summary.
In particular I’m not asking for “one correct way” for an implementation to
support enablement/disablement. I’m asking for “any way” for an implementation
to support enablement/disablement.
an implementation to support enablement/disablement is not appropriate
not least because the benefits of a given approach may well depend upon the use
case.
Example: One can imagine a network where MP is the norm and a given operator
might wish to NOT have to configure enablement in the interest of
configuration simplification. I see no reason why this should be declared
"illegal" just because others might not use that deployment strategy.
[Bruno] Nobody has asked this scenario to be declared “illegal”.
In particular I’m not asking for a “default behavior”. I’m asking for
“Providing appropriate controls to enable/disable the sending of MP-TLVs as
discussed in Section 7.1”
Straw man fallacy : 2
Suggestions/recommendations as to how an implementation might ease
deployment are valuable and these are discussed in the draft - and I believe
we do have consensus as to recommended best practices.
I therefore believe the current wording is appropriate and should not be
changed. The only change that needs to be made to the draft
is to change "essential" to "important" in Section 7 (for consistency).
[Bruno] Sure, let’s make the network robustness even weaker…
I appreciate the passion associated with this discussion - but I am hopeful
that this resolution is acceptable to all.
[Bruno] I’m not seeing a resolution and nothing has been changed. Hence my
position has not changed.
Regarding Section 4.1, any interoperability issues with link identifiers
are not introduced by MP. If the WG feels there is an issue here, it should
be taken up outside of MP as it could impact two-way connectivity checks
even in non MP-TLV cases.
I am not suggesting that such work is necessary - only indicating the correct
context in which such work should be done if it is to be done at all.
As far as the current wording in Section 4.1, it intentionally allows
existing implementations which successfully interoperate sending a subset
of link identifiers to continue to do so.
[Bruno] One may favor protection of existing implementations over protection of
the network. That’s a fine opinion. But there are opposite opinions.
--Bruno
Les
____________________________________________________________________________________________________________
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.
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
