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

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Sun, 4 Jul 1999 17:42:03 -0400 (EDT)

Just a thought. You specifically said this should not appear in
a pseudonode LSP. Given that it's optional, is there any reason
to preclude it being in a pseudonode LSP? Might it be useful to
have a name for the pseudonode to specify which LAN it is, or
even which VLAN it is? (the router would have to be configured
with a name for each LAN it was connected to in order to do this)

Also, might it be easier to say it should be in fragment 0? That way
there can't be confusion with having it in two different fragemnts
with 2 different names.

Radia

---

From: Tony Li <[email-masked]>
Date: Mon, 05 Jul 1999 16:02:51 -0700

Radia (et. al.),

> to preclude it being in a pseudonode LSP?

That would create semantic ambiguity, which would be highly
inappropriate.  There is nothing in the Internet architecture right now
that associates a DNS name with a LAN today.  While I can certainly see
some practical benefits from doing so, it would seem like one should
first argue about the architectural benefits before putting the
mechanism in place.  In the meantime, it would seem best not to muddy
the waters and to continue to associate a DNS hostname with a host.  ;-)

There's also the small architectural issue of dealing with P2P links.
Even if you do decide that you want to name LANs, symmetry insists that
we be able to name P2P links as well.  How do we encode that?

> there can't be confusion with having it in two different fragemnts

I think you have the same confusion if it appears twice in fragment
zero.  The draft could probably quickly resolve this by simply picking
one (say the first ;-) TLV in the lowest fragment.

There are other criticisms of this draft that have been discussed in the
WG that are (sadly) still not addressed:

1) What happens when the fragment containing the name is withdrawn?
Should the name be purged from the hostname table?  Or is this a timer
based cache?

2) How does one deal with two systems advertising the same hostname?

3) What happens to name translation if the hostname table is a cache and
the value is purged?  The operational implication here is that if your
network is having a crisis and your link state database is in flux,
that's also when it will be hardest to get hostname translation.

Regards,
Tony

---

From: Naiming Shen <[email-masked]>
Date: Mon, 05 Jul 1999 21:40:55 -0700

]
 ]Radia (et. al.),
 ]
 ]
 ]> Just a thought. You specifically said this should not appear in
 ]> a pseudonode LSP. Given that it's optional, is there any reason
 ]> to preclude it being in a pseudonode LSP?
 ]
 ]That would create semantic ambiguity, which would be highly
 ]inappropriate.  There is nothing in the Internet architecture right now
 ]that associates a DNS name with a LAN today.  While I can certainly see
 ]some practical benefits from doing so, it would seem like one should
 ]first argue about the architectural benefits before putting the
 ]mechanism in place.  In the meantime, it would seem best not to muddy
 ]the waters and to continue to associate a DNS hostname with a host.  ;-)
 ]
 ]There's also the small architectural issue of dealing with P2P links.
 ]Even if you do decide that you want to name LANs, symmetry insists that
 ]we be able to name P2P links as well.  How do we encode that?
 ]
 ]> Also, might it be easier to say it should be in fragment 0? That way
 ]> there can't be confusion with having it in two different fragemnts
 > with 2 different names.
 ]
 ]I think you have the same confusion if it appears twice in fragment
 ]zero.

Exactly. In practice, it will probably always show up in the first
fragment. But in case someday, people want to implement such that
this TLV takes a LSP fragment of its own.

 ]The draft could probably quickly resolve this by simply picking
 ]one (say the first ;-) TLV in the lowest fragment.

or the last one(the latest one by time).

 ]
 ]There are other criticisms of this draft that have been discussed in the
 ]WG that are (sadly) still not addressed:
 ]
 ]1) What happens when the fragment containing the name is withdrawn?
 ]Should the name be purged from the hostname table?  Or is this a timer
 ]based cache?

I would prefer it be cached for certain amount of time. This is specially
useful that we don't require the TLV be in the fragment zero. So we are
not sure if it is really withdrawn, or being pushed to another fragment and
transmitted later.

 ]
 ]2) How does one deal with two systems advertising the same hostname?

I don't think we care. If the user decides to name two routers exact
the same name, we should display both systems with the same name. An
implemention of course can optionally spit out some warning message.

 ]
 ]3) What happens to name translation if the hostname table is a cache and
 ]the value is purged?  The operational implication here is that if your
 ]network is having a crisis and your link state database is in flux,
 ]that's also when it will be hardest to get hostname translation.

If you are talking about the name value is purged because of the LSP itself
is purged, then the LSP or the system probably disappeared from the network
for a while, then we don't have a need to display it.

If a LSP with this TLV is constantly purged due to some network problem,
since the cache takes a while to timeout, and as soon as the new LSP with
this TLV comes in, the cache is updated. The name table should be relatively
stable.

Of course, when the a system advertises a new name, the name table should
be updated with the new name info right away. 

 ]
 ]Regards,
 ]Tony
 ]
 ]

 - Naiming

---

From: Tony Li <[email-masked]>
Date: Tue, 06 Jul 1999 10:46:29 -0700

> or the last one(the latest one by time).

Whoa.  The last one would mean to me the highest numbered fragment, farthest at
the end of the PDU.  Time is not involved.

If you did specify time, then you have to worry about race conditions between
the flooding of different fragments.  I don't think you really meant that....

> not sure if it is really withdrawn, or being pushed to another fragment and

This is entirely reasonable.  The draft should probably say something like this,
plus some guess as to how long the name should be cached.  My swag would be
something like the entire lifetime of the fragment plus another 5 minutes.

> implemention of course can optionally spit out some warning message.

Seems reasonable.  Probably needs to be explicitly stated.

> for a while, then we don't have a need to display it.

Not at all.  Other fragments may still be floating around and may be valid.  You
still want to display the hostname.  Exactly the situation that would happen if
there is fun with flooding.

> this TLV comes in, the cache is updated. The name table should be relatively

Exactly the point of having a cache lifetime.

> be updated with the new name info right away.

And presumably the old name can be removed immediately.

Tony

---

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

The recommendation probably shouldn't be specific about
caching of name/address table entries.  That isn't really
part of the protocol, and access to the name-address
table will only be accessible via proprietary interface
(unless you define the MIB for it also).

Leaving the caching unspecified permits systems to retain
the information (in the LSDB) and "support" the option
(by providing some access to it) without requiring another
data structure.  Caching could be recommended, but should
not be required.

But if you're serious enough to put the table in the MIB,
then caching behavior should be defined.  There are
several alternatives, off the top of my head:

  MIB Hostname table support could be optional, even if
  you support the hostname option in your LSPs.

  Caching of entries could be optional, even if you
  support the MIB hostname table.

  The MIB hostname table could have a cache-time attribute,
  which could optionally be settable, with a recommended
  default of 5 minutes (or whatever), but an acceptable
  value of zero (no caching).

I recommend that the first option encountered in the lowest
numbered LSP be used.  I agree that "newest" is not computable
from the information available, since LSP sequence numbers
aren't coordinated between LSP segments.

The option should be *recommended* to be placed in LSP zero
so that it will be available during purging and after the
LSP has timed out but not flushed (if I remember the detailed
states of LSPs correctly.)

Regards,
Jeff

>And presumably the old name can be removed immediately.
____________________________________________________________________

  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: Mike Shand <[email-masked]>
Date: Wed, 07 Jul 1999 08:28:47 +0100

>states of LSPs correctly.)

No, LSP zero has no special significance to the update process. It only has
significance to the SPF, since other LSP fragments are only considered if
fragment zero is present. Hence all the 'important' information goes in LSP
zero.

So this information would naturally reside in LSP zero, but I take Jeff's
point that it would probably be unwise to waste the precious LSP zero space
(especially in the SONET environment), by requireing something which is not
essential.

I assume that we are saying that this option gets looked at when the LSP
arrives, as opposed to when the SPF is run. i.e. it doesn't have to be
reachable to be considered, and it will still  be considered if it exists
in a non-zero LSP fragment and the zero fragment is missing.

	Mike

---

From: Naiming Shen <[email-masked]>
Date: Wed, 07 Jul 1999 09:06:14 -0700

]
 ]
 ]Naiming Shen wrote:
 ]
 ]>  ]The draft could probably quickly resolve this by simply picking
 ]>  ]one (say the first ;-) TLV in the lowest fragment.
 ]>
 ]> or the last one(the latest one by time).
 ]
 ]Whoa.  The last one would mean to me the highest numbered fragment, farthest 
at
 ]the end of the PDU.  Time is not involved.
 ]
 ]If you did specify time, then you have to worry about race conditions between
 ]the flooding of different fragments.  I don't think you really meant that....

I actually meant the latest by time. If a router name is changed, but this
TLV is pushed onto another LSP fragment. If we use the lowest, or highest
fragment number to decide, then the new name might not be installed until
the old lsp timeout.

Yes, if there is an implementation constantly stuffs different names into
different lsp fragments, it does create race condition. But it might be
OK, since you can optionally give a warning if it toggles too much or just
live with multiple names;-) which can be a desirable feature.

So I guess the choices are if you want to learn the new name right away,
or you want to handle broken implementation.

 ]> Of course, when the a system advertises a new name, the name table should
 ]> be updated with the new name info right away.
 ]
 ]And presumably the old name can be removed immediately.

In order to do that, I think we need to use the first choice.

 ]
 ]Tony
 ]
 ]

 - Naiming