Subject: [Isis-wg] draft-simpson-isis-ppp-unique-00

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Apr 2011 18:25:17 +0100

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 25 Apr 2011 10:39:20 -0700

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?

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stewart Bryant (stbryant)
> Sent: Monday, April 25, 2011 10:25 AM
> To: isis-wg; [email-masked]
> Subject: [Isis-wg] draft-simpson-isis-ppp-unique-00
> 
> ISIS WG
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 25 Apr 2011 13:31:33 -0700

William -

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.

   Les

> From: William Allen Simpson [mailto:[email-masked]]
> Sent: Monday, April 25, 2011 1:01 PM
> To: Les Ginsberg (ginsberg)
> Cc: Stewart Bryant (stbryant); isis-wg; [email-masked]
> Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00
> 
> On 4/25/11 1:39 PM, Les Ginsberg (ginsberg) wrote:
> 1) it's already completed, and ready to be published as an RFC.
> 
> 2) it was originated and discussed in the PPP WG, with copious CC's to
> the TRILL WG, while also BCC'ing the ISIS WG chairs.
> 
> 3) various folks have all indicated it's not in the current charter of
> their WGs.
> 
> 4) I was given the options of:
>    a) amending WG charters.
>    b) starting a new WG for this item only.
>    c) independent submission.
> 
> 5) Once the currently excruciating and lengthy IESG process for
> independent submissions of Proposed Standards was explained, the ISE
> Experimental route is the only remaining viable option.
> 
> So, best to send me any (unlikely) corrections directly.  It's the
> second shortest RFC I've ever written, and it's mostly boilerplate.
> 
> 
> As noted above, everybody says it's not in the current charters.
> 
> But I'm open to suggestions -- just as long as they don't hold up the
> pppext-trill and other TRILL documents.  We've already wasted 3+
months
> (since Jan 24th) discussing process.  I'm really, Really, *REALLY*
> tired of arguing about process!
> 
> Remember the days when 4 week last calls were for Best Current
> Practices,
> and we could somehow manage to do a Proposed Standard in under a
month?
> While it only took a minimum 2 weeks to form a Working Group?
> 
> Perhaps we'll try PS after there are 2 interoperable
> implementations....
> 
>

---

From: mike shand <[email-masked]>
Date: Tue, 26 Apr 2011 12:17:11 +0100

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.

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

---

From: Ross Callon <[email-masked]>
Date: Tue, 26 Apr 2011 10:55:34 -0400

To me the "high order bit" of this discussion is that the document needs to be brought into the IS-IS working group, and it would be a mistake to let it be published on the independent stream. 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of mike shand
Sent: Tuesday, April 26, 2011 7:17 AM
To: [email-masked]
Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00

	Mike

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 25 Apr 2011 17:45:09 -0400

> aware that it was discussed on the TRILL list and the TRILL folks -

So you already knew about the draft, this is not a surprise to you....

It was raised at the Prague meeting -- and (as I mentioned previously)
the ISIS WG chairs themselves.

Neither Internet nor Routing Area ADs decided to sponsor this draft.

> I encourage you to submit the draft to the IS-IS WG.
That train has left the station.  If you have any technical improvements,
I'd appreciate them promptly.  Thank you.

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 25 Apr 2011 16:00:44 -0400

But I'm open to suggestions -- just as long as they don't hold up the
pppext-trill and other TRILL documents.  We've already wasted 3+ months
(since Jan 24th) discussing process.  I'm really, Really, *REALLY*
tired of arguing about process!

Remember the days when 4 week last calls were for Best Current Practices,
and we could somehow manage to do a Proposed Standard in under a month?
While it only took a minimum 2 weeks to form a Working Group?

Perhaps we'll try PS after there are 2 interoperable implementations....

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 26 Apr 2011 11:37:17 -0700

+1

   Les

> Behalf Of Ross Callon
> Sent: Tuesday, April 26, 2011 7:56 AM
> To: Mike Shand (mshand); [email-masked]; Stewart Bryant (stbryant)
> To me the "high order bit" of this discussion is that the document
> needs to be brought into the IS-IS working group, and it would be a
> mistake to let it be published on the independent stream.
> 
> Ross
> 
> Behalf Of mike shand
> system IDs in the neighbor using ISHs. But the problem arises across
an
> entire
> and indeed probable that the offending system IDs are not adjacent,
but
> will

---

From: Tony Li <[email-masked]>
Date: Tue, 26 Apr 2011 11:51:36 -0700

+2

---

From: John E Drake <[email-masked]>
Date: Tue, 26 Apr 2011 13:21:28 -0700

+ 1  From what Mike wrote, I get the distinct impression that this document is 'ill considered'.  

Sent from my iPhone

> Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, April 26, 2011 11:37 AM
> To: Ross Callon; Mike Shand (mshand); [email-masked]; Stewart Bryant
> (stbryant)
> > an area within 10 seconds". Surely this doesn't mean a simple
> mismatch
> > of area
> > occur benignly when a system has multiple interfaces onto the same
> LAN
> > ( either
> > 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

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 27 Apr 2011 02:05:43 +0100 (BST)

+3

________________________________
From: Tony Li <[email-masked]>
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Ross Callon <[email-masked]>; [email-masked]; Mike Shand (mshand) <[email-masked]>
Sent: Wednesday, 27 April 2011, 0:21
Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00

+2