Subject: Re: draft-ietf-isis-dyname-01.txt

From: "Jerome P Moisand" <[email-masked]>
Date: Tue, 6 Jul 1999 13:09:25 -0400

Er... my dear friend Jeff...

I guess I agree with the philosophical principles you're explaining here...
but... there is another flooding protocol that has been introduced in the
SONET world... and that flooding protocol created very severe headaches for
many of us in the SONET world... See what I mean?

If only IS-IS could flood TIDs as a particular form of hostnames within a
IS-IS level1 area, then TARP flooding is no longer useful in these level 1
areas, we only need to keep keep it at level2. Which would be a
***tremendous*** enhancement. And also a very nice step in the way of
auto-discovery of topologies & inventories.

Actually, when we started to think about TARP LAN storms with Bruno Rijsman,
I told him that it was probably somewhat short-sighted to simply address
storms on LANs, and we'd better address storms in Level 1 areas... for
exemple by extending IS-IS to carry TIDs (complementing that by some
explicit NET to TID translations when receiving an LSP from a old IS-IS
implemention not sending its TID) and then each system could maintain the
(TID/NET) list for all other systems in the area. Well, we made the choice
to solve the LAN storm first, as a small (but quite needed) pragmatic step
(useful anyway for L2 flooding as well), and wait for the IS-IS WG to make
progress in that hostname parameter story.

Of course, a T1.245/X.500 directory with auto-registration would even avoid
Level2 flooding, but well, no doubt the robustness of (a good) flooding has
value when the network is in bad connectivity shape.

In a nutshell, I strongly support what the IS-IS WG is doing. For SONET, but
also for any kind of DCN infrastructure. The hostname (or TID) is a
parameter that is essential enough to be addressed separately. If I may draw
an analogy, DNS is a directory restricted to host/address resolution and
*not* a general-purpose directory; why? well because of the very special
role of hostnames...

Jerome

PS. for those of you who are lucky enough to *not* have any idea of what I'm
speaking about (the wonderful TARP protocol used on SONET management
networks), do *not* rush to the corresponding specification (Bellcore
GR.253), no need to waste such a nice summer...   ;-) ;-)

-----Original Message-----
From: Jeff Learman <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Tuesday, July 06, 1999 12:47 PM
Subject: draft-ietf-isis-dyname-01.txt

>
>Please forgive me for joining this discussion late in the game,
>but let me add some considerations.
>
>Admittedly, putting host names in LSPs is a nifty idea,
>and is a simple solution to a practical problem.
>
>However, name-to-address mappings are relatively static and
>are not necessary for the operation of the routing protocol.
>Do we think it is wise to add information to be stored in every
>router in order to have a rarely used but reliable copy of this
>information?  The principal reason for using IS-IS to propagate
>this information is "because it's there".
>
>Just becuase IS-IS is a good reliable means for propagating information
>does not imply that it is the appropriate mechanism for flooding
>all information that would be useful to flood.  Noted, the information
>in this case is added to assist in maintaining the routing protocol.
>
>But is that the end -- is the host name of a router sufficient information?
>We also want information like the manufacturer, the physical location,
>and the contact person responsible for the router.  Should this information
>also be flooded and required to be stored by every IS in the area or
>domain?  Adding unnecessary options to LSPs is particularly troublesome
>in SONET networks, where most systems are routers and very few are end
>systems.  Exacerbating this, the max LSP size is  512 bytes thanks to
>an unfortunate choice of MTU size on SONET links.
>
>My guess is that the host name alone takes little enough space and
>adds sufficient value that it is worth serious consideration, and that
>the others may be past the point of diminishing returns.  I suggest that
>at least, the document should mention this tradeoff and justify it.
>
>I recommend that the option not be required to be present in LSP zero,
>because that will affect other limitations that are based on the
>max LSP size and information that is required in LSP zero.  It is not
>required for the IS-IS protocol to operate properly, and therefore
>can appear in any LSP.
>
>Regards,
>Jeff
>____________________________________________________________________
>
>  Jeff Learman                           Internet:     [email-masked]
>  Engineering Manager                    Voice:     (734)-975-7323
>  ONE (Open Networks Engineering, Inc)   Fax:       (734)-975-6940
>  2725 South Industrial Pkwy, Suite 100
>  Ann Arbor, MI  48104  USA
>____________________________________________________________________

---

From: Jeff Learman <[email-masked]>
Date: Tue, 06 Jul 1999 14:15:02 -0400

Jerome,

I suggest we avoid any discussion of TARP in this
forum, at the cost of embarassment if they ask us
about it!  (Or would you like to explain it and
face the guffaws, giggles, and knee slapping?)

Note that TARP handles name-address resolution
for ESs, not just ISs, whereas the proposal only
handles hostnames of routers.  There are some other things,
too, which I'll discuss with you off-line, and anyone
interested can send me email to ask for it.

And while it's silly to reinvent a flooding
mechanism when IS-IS has a robust one, it
is certainly possible (not to say easy) to use the
IS-IS flooding mechanism in a new protocol.

Jeff

>GR.253), no need to waste such a nice summer...   ;-) ;-)
... remainder deleted ...
____________________________________________________________________