Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02

[Alvaro Retana <[e-mail]>]

On August 10, 2019 at 6:44:49 PM, Les Ginsberg (ginsberg) (
[e-mail]) wrote:

Les:

Hi!

I have a couple of comments below related to backwards compatibility: I
think there is a way to not change the behavior of current implementations
*and* not throw out old implementations.  See below.

Thanks!

Alvaro.

...

245            Note: Implementations based on earlier drafts of RFC 5306

246            may not include this field in the TLV when the RA bit is set.

247            In this case, a router that is expecting an RA on a LAN
circuit

248            SHOULD assume that the acknowledgement is directed at the
local

249            system.



[major] I think it is time we stop catering to old/non-compliant
implementations.  The last time that a draft didn't include the System ID
was draft-ietf-isis-restart-03 in March 2003: more than 15 years ago!!



[Les:] While I am in sympathy with your position, the existing RFC has
allowed implementations based on early versions of the draft to exist and
defined how to interoperate with them. It is therefore conceivable that an
implementor simply never chose to update their implementation since they
never had an interoperability problem reported. I do not see the value in
removing this interoperability. The lack of this support would only be
meaningful in the event multiple systems on the same LAN were restarting at
the same time – which of course is possible but not probable. I will
continue to listen if you REALLY feel strongly about this, but in the
spirit of “being generous in what you receive” I left this unchanged.

We should have caught and eliminated the problem when rfc3874 was
published. <sigh>  BTW, the text above should mention rfc3874 and not
rfc5306.

<rant> IMO, catering to non-standard implementations in a formal
specification devalues the standards process: if the purpose is to create
interoperable implementations, but we’re still going to bend over backwards
to allow non-compliant implementations (with the product of the WG, the
consensus, etc.), then why are we going through the pain of agreeing on and
standardizing anything?  We might as well just let anyone implement
anything…or never change the original draft if specifications already
exist…  </rant>

In this case, making the System ID optional, and explaining how/when it
should be used (as you did above), would fix the issue and bring
non-compliant implementations into the fold.  IOW, I think we would all be
happy if the wording changed from “allow non-compliant implementations” to
“this field is optional”…for example:

OLD>

   Required when the RA or PA bit is set. Otherwise

   this field SHOULD be omitted when sent and

   MUST be ignored when received.


NEW>

   This field is required when the PA bit is set, and MAY be present when
the

   RA bit is set.  Specifically, it is used when multiple systems on the
same

   LAN are restarting {more details}. If the RA or PA bit is not set, this

   field SHOULD be omitted when sent and MUST be ignored when received.


...

...

428       While the adjacency is in planned restart state the following
actions

429       MAY be taken:



[major] The steps below are optional (MAY)....that is ok.  (a) talks about
a compromised ability to flood updates on a LAN is adjacencies are not
reset, which sound very serious to me.  What are the considerations for an
implementation/deployment to decide using these optional actions?  Should
they be used on LANs, but not necessarily in other link types (just as an
example)?



[Les:] You have agreed that the use of MAY is appropriate here. Which means
all of the text describing what might cause the neighbor of the restarting
router to choose to bring the adjacency down is not normative.

MAY is a Normative keyword, so the text *is* Normative…the actions are
Optional.

We did describe a significant issue that would occur on a LAN if action
were not taken, but as we are allowing that none of the actions are
normative I do not see that the use of MUST would be appropriate in the
description.

Sorry, that was not the question.  I’m not asking (here) why the actions
are not mandatory.

Let me try again…. If the actions are optional (MAY), when might an
implementation decide that one of them is an important action to take?  For
example,  (c) makes it optional to suppress LSP/*SNPs…can you provide
guidance to when/why an implementation might decide to implement this
suggestion and when it might not?

In the end, I just think that if you’re offering options, then it would
make the specification better if you provided guidance on when it might be
more important to use those options and when it might not.  If you can’t
provide additional guidance, then we can move on.



I therefore left this text unchanged.



[minor] The actions below are independent of each other, right?  It may be
worth mentioning that.

[Les:] I have rephrased this as “some or all of the following actions MAY
be taken”.





431       a.  If additional topology changes occur, the adjacency which is
in

432           planned restart state MAY be brought down even though the hold

433           time has not yet expired.  Given that the neighbor which has

434           signaled a planned restart is not expected to update its

435           forwarding plane in response to signaling of the topology
changes

436           (since it is restarting) traffic which transits that node is
at

437           risk of being improperly forwarded.  On a LAN circuit, if the

438           router in planned restart state is the DIS at any supported

439           level, the adjacency(ies) SHOULD be brought down whenever any
LSP

440           update is either generated or received so as to trigger a new
DIS

441           election.  Failure to do so will compromise the reliability of

442           the Update Process on that circuit.  What other criteria are
used

443           to determine what topology changes will trigger bringing the

444           adjacency down is a local implementation decision.



[nit] s/received so as to/received, so as to



[major] "adjacency(ies) SHOULD be brought down...Failure to do so will
compromise the reliability of the Update Process on that circuit."  When is
it ok to not bring these adjacencies down?  If the operator already decided
to deploy these optional steps, why wouldn't the adjacencies be always
brought down?  IOW, why is MUST not used?

[Les:] Answered above

If this option is chosen, why wouldn’t the adjacency be brought down?

>From above, I understand the action in (a) is optional…no problem.  But if
an implementation chooses to implement it, why wouldn’t the adjacency be
brought down?