Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID

["Les Ginsberg (ginsberg)" <[e-mail]>]

William -

I am attaching Mike Shand's post of 4/26 to the isis-wg. Perhaps you
never saw this if you are not a WG member.

   Les


> -----Original Message-----
> From: William Allen Simpson [mailto:[e-mail]]
> Sent: Wednesday, June 01, 2011 10:03 AM
> To: Les Ginsberg (ginsberg)
> Cc: James Carlson; Stewart Bryant (stbryant); PPP Extensions; Donald
> Eastlake; [e-mail]
> Subject: Re: [rbridge] [Pppext] TRILL, IS-IS, and System ID
> 
> On 6/1/11 12:32 PM, Les Ginsberg (ginsberg) wrote:
> > (Please include isis-wg on this thread.)
> >
> No.  It bounces, and ends up in my spam folder.  There's some kind of
> moderator for non-members.
> 
> 
> > I have a BIG PROBLEM with references to
> >
> >    [8] W. Simpson, "Generation of Unique IS-IS System Identifiers,"
> >         (draft-simpson-isis-ppp-unique), work in progress, March
2011
> >
> > This has been publicly reviewed and noted (and I think quite
> correctly
> > so) as being seriously flawed. So even a passing suggestion that
this
> > might be a reasonable alternative for someone seems at best very
> > premature.
> >
> This is *NOT* true!  You have been aware of the draft for months, and
> had every opportunity to review.  The only comments you've sent me are
> neither textual nor protocol relevant.  Your comments were:
> 
> 
> On 4/25/11 1:39 PM, Les Ginsberg (ginsberg) wrote:
> # Is there a reason why the author is averse to bringing the draft to
> the
> # WG?
> #
> # Is there a reason why the WG chairs/ADs are not "encouraging" the
> author
> # to bring the draft to the WG?
> 
> 
> On 4/25/11 4:31 PM, Les Ginsberg (ginsberg) wrote:
> # I am not aware that you EVER sent this to IS-IS WG for comments. I
am
> # aware that it was discussed on the TRILL list and the TRILL folks -
> # quite correctly - said this had nothing to do w TRILL. I don't
follow
> # the PPP WG - but I could easily imagine that they would have said
the
> # same thing. As you propose a change in behavior for IS-IS
> # implementations which is visible on the wire:
> #
> # <snip>
> # After detecting a conflicting System Identifier in a neighbor, or
> #     receiving 3 or more IS-IS Hellos and failing to resolve
> participation
> #     in an area within 10 seconds, an implementation conforming with
> this
> #     specification MUST generate a replacement System Identifier
using
> one
> #     of the techniques specified above.
> # <end snip>
> #
> # it seems a bit obvious that the IS-IS WG would be an appropriate
> place
> # to pursue the work.
> #
> # As to the need for speed in publishing this, I would point out that
> the
> # IS-IS protocol has been successfully deployed for 20 years and this
> # issue has not been a show stopper. That is not to say that your
> proposal
> # may not have merit - but any suggestion that this is a precondition
> for
> # publishing other IS-IS related drafts is flawed in my opinion.
> #
> # I encourage you to submit the draft to the IS-IS WG.
> #
> Five (5) months ago, that might have been helpful, but the work has
> been
> completed and ready for publication for some time.  There is no need
to
> "pursue the work" in ISIS, since that implies there is more work.  I'm
> not interested in unpaid make-work projects.
> 
> There is no need to "submit" to ISIS.  There are no oaths of fealty
> involved.  I've included (and acknowledged) all the useful comments
> received from ISIS WG members.

--- Begin Message ---

I have some comments on this draft.

    If a duplicated MAC is used as a System Identifier within an IS-IS
    area, this leads to the condition colloquially called "LSR War".
    Currently, IS-IS has no method to detect or resolve such conflicts.

It is something of an exaggeration to say that IS-IS has NO method to
detect this situation. It will result in the affected systems persistently
increasing the sequence numbers of their LSPs, in an attempt to assert
their own LSPs over the duplicates. Most implementations will detect this
condition and raise appropriate system warning messages. Admittedly,
the consequences, while this persists, are quite serious.

    After detecting a conflicting System Identifier in a neighbor, or
    receiving 3 or more IS-IS Hellos and failing to resolve participation
    in an area within 10 seconds, an implementation conforming with this
    specification MUST generate a replacement System Identifier using one
    of the techniques specified above.

I don't understand this paragraph. It talks about detecting the conflicting
system IDs in the neighbor using ISHs. But the problem arises across an entire
flooding domain (a single level 1 area or the level 2 domain). It is possible,
and indeed probable that the offending system IDs are not adjacent, but will
still cause the same level of disruption.

I also don't understand what is meant by "failing to resolve participation in
an area within 10 seconds". Surely this doesn't mean a simple mismatch of area
address, or any other reason for failing to bring up an L1 adjacency. I'm guessing
the author means receiving a hello with the same system ID as itself? But this can
occur benignly when a system has multiple interfaces onto the same LAN ( either
deliberately or by some bridging misconfiguration), and it is indeed hearing its own
hellos.

So this seems to make no sense at all, and clearly wouldn't work.

For it to work, it would have to be based on receiving an LSP which somehow indicated
the conflict. But receiving your own LSPs (with your own system ID) is a normal
occurrence, especially when rejoining a domain after a crash etc. So a means needs to
be provided to distinguish the common benign case, from a genuine  doppelganger.

Other that using some other "more unique" id to distinguish really different
system (which just punts the problem), it seems that some variant of the
normal detection method (i.e. detecting a persitent sequence number increment), is
the only viable alternative. Yet this draft says nothing about such a mechanism.

Whatever method were chosen, it would have to be proof against false positives, since
accidentally invoking a changed system ID would seem to make the cure worse than the disease.

Indeed, there seems to be a danger that bringing up a new system with an incorrectly
assigned system ID (the usual case is accidentally joining a test network to
the production network) would cause the existing (and previously stable) system to change
its ID.

Note that gratuitously changing a system ID can affect things other that the
operation of IS-IS itself. For example the system ID is often used as the
key in the hash function for preventing polarisation in hop by hop forwarding ECMP
paths, so changing the system ID is likely to affect traffic patterns adversely.


This whole thing needs to be MUCH, more carefully thought out, if indeed a solution
is to be attempted.

	Mike





On 25/04/2011 18:25, Stewart Bryant wrote:
> ISIS WG
>
> It seems likely that draft-simpson-isis-ppp-unique-00 will
> be submitted as an experimental submission on the
> independent stream.
>
> Please look out for it.
>
> If you have any views on this document please make them known.
>
> - Stewart
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
_______________________________________________
Isis-wg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/isis-wg

--- End Message ---