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

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Jun 2011 14:56:08 +0100

Bill

The discussion of suitable methods of ISIS and hence TRILL
SystemID uniqueness needs to take place on the ISIS list
(copied) regardless of the data link technology under
consideration.

James I am fine with your proposed text.

Stewart

On 01/06/2011 14:19, William Allen Simpson wrote:
> Obviously, Stewart is wrong.  We've gone to great lengths to ensure 
> PPP is
> zero configuration.  We never need to buy and burn IEEE MAC identifiers.
>
> TRILL seems to have zero configuration design goals, too.
>
> Therefore, James is also wrong.  This is not an operator issue.  You
> should *NOT* put this burden on operators.  It would really help for
> anybody with aspirations of designing protocols to have actually been an
> operator, and pay attention to discussions on the NANOG list!
>
> As a personal example, just last summer I spent *many* hours trying to
> figure our what was happening as a political campaign couldn't get their
> wireless access point to work.  It was very flaky.  At long last, traces
> discovered that the AP had a conflicting MAC with another device at
> another office somewhere else in the Comcast region.  You cannot expect
> political operatives (and quite frankly any other business) to fix this.
>
> Therefore, this is a protocol design issue.  I've been trying to live 
> with
> the various compromises on language, but this goes too far!
>
> Technically, that MUST is certainly wrong.  There's no guarantee of
> uniqueness, and uniqueness is required by both ISIS and TRILL.
>
> Moreover, there's no guarantee that a hot swappable or card or board 
> based
> device will not become (even temporarily) a PPP-only device.  To meet 
> that
> MUST, every vendor of PPP devices will have to burn an IEEE number for
> every device.  Yet, it still might not work!
>
> That's simply wrong!  There's a lot of nonsense in IETF protocols, but we
> don't have to add more here and now.
>
>
> On 5/31/11 2:20 PM, Donald Eastlake wrote:
>> James,
>>
>> I'm fine with your suggested tweak of Stewart Bryant's wording.
>>
>> Thanks,
>> Donald
>> =============================
>>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>   155 Beaver Street
>>   Milford, MA 01757 USA
>>   [email-masked]
>>
>>
>> On Tue, May 31, 2011 at 1:05 PM, James 
>> Carlson<[email-masked]>  wrote:
>>> As part of IETF review, the Routing ADs are looking over
>>> draft-ietf-pppext-trill-protocol-06.  Not too surprising to me -- given
>>> that I still think it's far out of scope -- the text concerning IS-IS
>>> System IDs is causing trouble in that review.  See this thread:
>>>
>>> http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533
>>>
>>> I wish I could leave the worms safely in the can, but it's looking like
>>> that might not be one of the options.
>>>
>>> Instead of the reference to Bill Simpson's draft, Stewart Bryant
>>> suggested replacement text like this:
>>>
>>>   ISO/IEC 10589 states that it is the responsibility of the routeing
>>>   domain administrative authority to enforce the uniqueness of the
>>>   system ID. In cases where a zero configuration system is
>>>   supplied the system manufacturer MUST install a suitable
>>>   unique identifier at manufacturing time. One way to achieve
>>>   this is for the manufacturer to use a unique IEEE MAC address
>>>   following the allocation procedures normally used in the
>>>   manufacture of an Ethernet interface.
>>>
>>> This tosses the issue back into the implementor's lap (which,
>>> incidentally, is exactly where I think the problem belongs), and
>>> suggests an existing and known solution where a MAC identifier may be
>>> allocated for the system itself and used as a global ID to construct 
>>> the
>>> necessary IS-IS System ID.
>>>
>>> For use in this draft, I would alter the wording slightly to indicate
>>> that zero-configuration is strongly preferred for TRILL (as guidance),
>>> and that obtaining a suitable identifier is the implementor's
>>> responsibility, rather than just saying "in cases where."
>>>
>>> Would this change fly without breaking consensus?  Or do we have to
>>> start over?
>>>
>>> -- 
>>> James Carlson         42.703N 71.076W<[email-masked]>
>>> _______________________________________________
>>> Pppext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pppext
>>>
>> _______________________________________________
>> Pppext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pppext
>>
>
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Jun 2011 15:19:10 +0100

Bill

Stewart

Sending again with the ISIS WG in the cc list not the BCC list.

---

From: James Carlson <[email-masked]>
Date: Wed, 01 Jun 2011 10:54:03 -0400

> operator, and pay attention to discussions on the NANOG list!

It's worth noting that I said "implementor" not "operator."  Perhaps the
language I'm using isn't clear.  By "implementor," I mean the person who
designs the hardware and software components that will be sold as a
product claiming to support TRILL.  I do not mean the person who buys
these products and installs them in a network.

Like you, I do not believe that it's appropriate or reasonable for
general-purpose TRILL implementations to require any sort of action on
the part of the person installing and using the equipment -- that is,
the "operator."  I've never suggested that as a solution, so the straw
man doesn't work here.  Nor do the ad-hominem jibes.

However, unlike you, I do not believe that the IETF must resolve this
potential system-level design issue.  Instead, I still strongly prefer
to leave it up to the people designing and building systems.  If they
can't resolve this relatively simple problem in a reasonable way then,
frankly, I have no faith that they can get any of the other million or
so complex system design decisions right.

Most importantly, I don't want to be dictating anything about IS-IS
design issues from within the PPP Extensions working group.  It's just
not appropriate or even feasible.  That's why I agree with the ideas
behind Stewart Bryant's text.

All that said, I don't really care.  This is a tempest in a teapot.  I
can mash together both texts if the Routing ADs are willing to accept a
passing reference here to a draft that, in their words, hasn't even been
considered by the IS-IS community.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Jun 2011 16:24:49 +0100

James,

I believe that any departure from the text in ISO10589 needs
to be discussed in the ISIS WG.

- Stewart

---

From: James Carlson <[email-masked]>
Date: Wed, 01 Jun 2011 11:50:48 -0400

> to be discussed in the ISIS WG.

"Any" departure?  No matter how subservient?  That seems as inflexible
as the other end of this spectrum.

If I suggested text like this, would it require ISIS WG discussion, and,
if so, what's the chance that this discussion would terminate in a
positive way?

   3. An implementation that has only PPP links might have no
      Organizationally Unique Identifier (OUI) that can form an IS-IS
      System ID.  Resolving that issue is outside the scope of this
      document, however it is strongly RECOMMENDED that all TRILL
      implementations have at least one zero-configuration mechanism to
      obtain a valid System ID.  Refer to ISO/IEC 10589 regarding System
      ID uniqueness requirements.  Alternative solutions to this issue
      may also be defined in the future; see [8] for an example.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Jun 2011 17:10:54 +0100

On 01/06/2011 16:50, James Carlson wrote:
>        ID uniqueness requirements.
You are OK up to here since you conform to the current ISIS spec.

> Alternative solutions to this issue
This needs to be discussed in the ISIS WG, and I cannot vouch
for the outcome.

- Stewart

---

From: James Carlson <[email-masked]>
Date: Wed, 01 Jun 2011 12:32:45 -0400

> You are OK up to here since you conform to the current ISIS spec.

OK; that's good.

> This needs to be discussed in the ISIS WG, and I cannot vouch

I see.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Jun 2011 09:32:33 -0700

(Please include isis-wg on this thread.)

James -

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of James Carlson
> Sent: Wednesday, June 01, 2011 8:51 AM
> To: Stewart Bryant (stbryant)
> Cc: PPP Extensions; Donald Eastlake; [email-masked]; William Allen
> Simpson
> Subject: Re: [rbridge] [Pppext] TRILL, IS-IS, and System ID
> 
> Stewart Bryant wrote:
> >

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.

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Jun 2011 11:23:54 -0700

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

> From: William Allen Simpson [mailto:[email-masked]]
> Sent: Wednesday, June 01, 2011 10:03 AM
> To: Les Ginsberg (ginsberg)
> Cc: James Carlson; Stewart Bryant (stbryant); PPP Extensions; Donald
> Eastlake; [email-masked]
> On 6/1/11 12:32 PM, Les Ginsberg (ginsberg) wrote:
> No.  It bounces, and ends up in my spam folder.  There's some kind of
> moderator for non-members.
> 
> 
> 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.

Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00
From: "Mike Shand (mshand)" <[email-masked]>
To: <[email-masked]>
Date: Tue, 26 Apr 2011 04:17:11 -0700

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Jun 2011 11:44:36 +0100

On 01/06/2011 17:37, William Allen Simpson wrote:
> On 6/1/11 12:10 PM, Stewart Bryant wrote:
> Please point to the text in ISO10589 on configuring System Identifiers.
>
> Quote the section and page.

The following text:

ISO/IEC 10589:2002(E)
Page15
7.1.4    Administration and deployment of systems in a routeing domain
"It is the responsibility of the routeing domain administrative 
authority to enforce the requirements stated below in this clause"

ISO/IEC 10589:2002(E)
Page16 section (a) point 2
"Each system in an area must have an unambiguous ID; that is, no two 
systems (IS or ES) in an area may use the same ID value."

ISO/IEC 10589:2002(E)
Page16 section (b) point 1
"Each Level 2 Intermediate system within a routeing domain must have an 
unambiguous value for its ID field; that is,
no two level 2 ISs in a routeing domain can have the same value in their 
ID fields."

ISO/IEC 10589:2002(E)
Page148 Informational Annex B.1.1.3 The identifier (id) field
para 3
"Second, a considerable savings can be obtained in manual address 
administration for all systems in the routeing domain. If the ID is 
chosen from the ISO 8802 48-bit address space (represented as a sequence 
of 6 octets as specified in ISO/IEC 10039), the ID is known to be 
globally unique. Furthermore, since LAN systems conforming to ISO 8802 
often have their 48-bit MAC address stored in ROM locally, each system 
can be guaranteed to have a globally unambiguous NET and NSAP(s) without 
centralised address administration at the area level2). This not only 
eliminates administrative overhead, but also drastically reduces the 
possibility of duplicate NSAP addresses, which are illegal, difficult to 
diagnose, and often extremely difficult to isolate."

Seems to fully describe the intent of the authors.

> Please point to the text in ISO10589 on autonomously resolving 
> conflicting
> System Identifiers.
>
> Quote the section and page.
The text above seems to make it clear that the specifcation requires
resolution at either configuration or manufacturing time.

>
> Heck, I've not seen any reference to duplicate System Identifiers in
> ISO10589 anywhere.  Perhaps the standardese escaped my notice?

Please see Annex B.1.1.3

Stewart

---

From: James Carlson <[email-masked]>
Date: Thu, 02 Jun 2011 11:32:16 -0400

> You are OK up to here since you conform to the current ISIS spec.

It looks like we have convergence of sorts.  I will update the
specification to include the text above, and remove the reference to
William Simpson's IS-IS draft.

I realize this doesn't make everyone happy.  It's impossible to do so.
However, I do have an Area Director strongly suggesting this path, along
with concurrence from both other PPPEXT participants and RBridge
participants.  I'm going to call that "rough consensus" and drive on.

Anyone who disagrees ought to take the issue up with the IETF last call
process ([email-masked]) or, if necessary, the IESG.  For convenience,
the tracker entry is here:

https://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/

The responsible AD is Jari Arkko <[email-masked]>.  IETF last call
ends June 8th, 2011, and comments (with the draft file name in the
subject line) may be sent to [email-masked].