Subject: RE: [Isis-wg] I-D Action:draft-ietf-isis-wg-extlsp-01.txt

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 1 Nov 2007 17:48:20 -0700

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2007 5:51 AM
> To: Mike Shand (mshand)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-wg-extlsp-01.txt
> 
> hi mike,
> 
> cool tx.
> 
> also one note on TLV 23 and TLV 223 formatting. the text says that the
> TLV formatting is like TLV 22/222. i have some concerns with this and
> i'd like to have that slightly changed and exclude the 24-bit
> metric information in the TLV 23/223 formatting.
> 
> e.g.
> 
>    The proposed TLV 23 consists of:
> 
>       7 octets of system Id and pseudonode number
>       1 octet of length of sub-TLVs
>       0-247 octets of sub-TLVs,
>            where each sub-TLV consists of a sequence of
>                 1 octet of sub-type
>                 1 octet of length of the value field of the sub-TLV
>                 0-245 octets of value
> 
> 
>    The proposed TLV 223 consists of:
> 
>       2 octets of multi-topology ID - where the 4 MSBs are reserved.
>       7 octets of system Id and pseudonode number
>       1 octet of length of sub-TLVs
>       0-245 octets of sub-TLVs,
>            where each sub-TLV consists of a sequence of
>                 1 octet of sub-type
>                 1 octet of length of the value field of the sub-TLV
>                 0-243 octets of value
> 
> 
> 
> My understanding of TLV 23/223 is just to alias subTLV information and
> w/o a metric field there is no need to deal with cases where the
original
> TLV 22/222 metric is different than the TLV 23/223 TLV metric.
> 
> let me know your thoughts ?
> 

While I agree that it is desirable to avoid the potential problem of
having inconsistent metrics, I think the disadvantages of your proposal
outweigh the advantages. Consider the following:

In cases where there are multiple adjacencies between the same two
routers, for the purposes of the IS-IS Decision process it is only
necessary to advertise one IS-Neighbor. It is only because of additional
requirements (such as TE link information) that we need to advertise
IS-neighbor information for each link. If we were to adopt your
proposal, we would face the following alternatives:

1)Advertise TLV 22 for each link in original LSPs w minimal TE info (IP
interface address and neighbor address would be necessary to uniquely
identify each link) so as to obtain the metric. Then advertise TLV 23 in
extended LSPs w the remainder of the TE information.

This seems undesirable since it mitigates the space savings we can
achieve in original LSPs.

2)Modify the handling of metric information so that whenever TLV 23 is
used we include a TE default metric subTLV (#18) and that value is used
by TE for that link.

This does not provide us any space savings over including the metric in
the fixed portion of the TLV. It in fact costs a couple of octets due to
subTLV overhead. And it introduces inconsistency in the way information
is advertised/processed in the different TLVs - which complicates the
implementation.

It is also worth noting that "clever implementers" will observe that the
need to use both TLV 22 and TLV 23 occurs only for (one of) the lowest
cost links to a neighbor and that this could be avoided by advertising
the TE information for that link in TLV 22 (in original LSPs) while
using TLV 23 (in extended LSPs) for the remainder of the links to that
same neighbor. As the use of multiple links between neighbors is
commonplace, this still provides significant benefits.

In the case where we have both TLV 22 and TLV 23 for the same link and
the metrics differ, we do need to define clear rules about which metric
should be used. I would propose adding text which clearly defines that
the metric in TLV 22 MUST be used in such cases.

How does this sound?

   Les

> /hannes
> 
> On Wed, Oct 31, 2007 at 10:54:24AM +0000, mike shand wrote:
> | Yes. We spotted that:-)  Danny was going to fix it.
> |
> |    Mike
> |
> | >see section 4:
> | >
> | >--
> | >   The obvious drawback of static configuration of mappings is the
> issue
> | >   of scalability and maintainability. The network operators have
to
> | >   maintain the name tables. They have to maintain an entry in the
> table
> | >   for every router in the network, on every router in the network.
The
> | >   effort to create and maintain these static tables grows with the
> | >   total number of routers on the network.  Changing the name or
> | >   systemID of one router, or adding one new router introduced will
> | >   affect the configurations of all the other routers on the
network.
> | >   This will make it very likely that those static tables are
outdated.
> | >
> | >   Having one table that can be updated in a centralized place
would be
> | >   helpful. One could imagine using the DNS system for this. A
drawback
> | >   is that during the time of network problems, the response time
of
> DNS
> | >   services might not be satisfactory or the DNS services might not
> even
> | >   be available. Another possible drawback might be the added
> complexity
> | >   of DNS. Also, some DNS implementations might not support A and
PTR
> | >   records for CLNS NSAPs.
> | >
> | >   A third way to build dynamic mappings would be to use the
transport
> | >   mechanism of the routing protocol itself to advertise symbolic
names
> | >   in IS-IS link-state PDUs. This document defines a new TLV which
> | >   allows the IS-IS routers to include the name-to-systemID mapping
> data
> | >   in their LSPs. This will allow simple and reliable transport of
name
> | >   mapping information across the IS-IS network.
> | >
> | >--
> | >
> | >On Sat, Oct 20, 2007 at 10:40:02AM -0400, [email-masked]
> wrote:
> | >| A New Internet-Draft is available from the on-line
Internet-Drafts
> | >directories.
> | >| This draft is a work item of the IS-IS for IP Internets Working
Group
> of
> | >the IETF.
> | >|
> | >|
> | >| 	Title           : Simplified Extension of LSP Space for IS-IS
> | >| 	Author(s)       : L. Ginsberg, et al.
> | >| 	Filename        : draft-ietf-isis-wg-extlsp-01.txt
> | >| 	Pages           : 15
> | >| 	Date            : 2007-10-20
> | >|
> | >| This draft describes a simplified method for extending the LSP
space
> | >| beyond the 256 Link State PDU (LSP) limit defined in [ISO 10589].
> | >| This method is intended as a preferred replacement for the method
> | >| defined in [RFC 3786].
> | >|
> | >| A URL for this Internet-Draft is:
> | >|
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-extlsp-01.txt
> | >|
> | >| To remove yourself from the I-D Announcement list, send a message
to
> | >| [email-masked] with the word unsubscribe in the
body
> of
> | >| the message.
> | >| You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> announce
> | >| to change your subscription settings.
> | >|
> | >| Internet-Drafts are also available by anonymous FTP. Login with
the
> | >| username "anonymous" and a password of your e-mail address. After
> | >| logging in, type "cd internet-drafts" and then
> | >| 	"get draft-ietf-isis-wg-extlsp-01.txt".
> | >|
> | >| A list of Internet-Drafts directories can be found in
> | >| http://www.ietf.org/shadow.html
> | >| or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> | >|
> | >| Internet-Drafts can also be obtained by e-mail.
> | >|
> | >| Send a message to:
> | >| 	[email-masked].
> | >| In the body type:
> | >| 	"FILE /internet-drafts/draft-ietf-isis-wg-extlsp-01.txt".
> | >|
> | >| NOTE:   The mail server at ietf.org can return the document in
> | >| 	MIME-encoded form by using the "mpack" utility.  To use this
> | >| 	feature, insert the command "ENCODING mime" before the "FILE"
> | >| 	command.  To decode the response(s), you will need "munpack" or
> | >| 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> | >| 	exhibit different behavior, especially when dealing with
> | >| 	"multipart" MIME messages (i.e. documents which have been split
> | >| 	up into multiple messages), so check your local documentation on
> | >| 	how to manipulate these messages.
> | >|
> | >| Below is the data which will enable a MIME compliant mail reader
> | >| implementation to automatically retrieve the ASCII version of the
> | >| Internet-Draft.
> | >
> | >
> | >| _______________________________________________
> | >| Isis-wg mailing list
> | >| [email-masked]
> | >| https://www1.ietf.org/mailman/listinfo/isis-wg
> | >
> | >
> | >_______________________________________________
> | >Isis-wg mailing list
> | >[email-masked]
> | >https://www1.ietf.org/mailman/listinfo/isis-wg
> | >
> | >
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 05 Nov 2007 15:11:09 +0100

> the metric in TLV 22 MUST be used in such cases.

reasonable :-) ... thanks - /hannes