Dismiss
There will be a system update on Friday, May 5th, 6 PM ET. You may experience a brief service interruption.
Browse Prior Art Database

Dynamic Hostname Exchange Mechanism for IS-IS (RFC2763)

IP.com Disclosure Number: IPCOM000003361D
Original Publication Date: 2000-Feb-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

N. Shen: AUTHOR [+2]

Abstract

Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 38% of the total text.

Network Working Group N. Shen

Request for Comments: 2763 Siara Systems

Category: Informational H. Smit

Cisco Systems

February 2000

Dynamic Hostname Exchange Mechanism

for IS-IS

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

Currently, there does not exist a simple and dynamic mechanism for

routers running IS-IS to learn about symbolic hostnames. This

document defines a new TLV which allows the IS-IS routers to flood

their name to system ID mapping information across the IS-IS network.

1. Introduction

IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a

node in the network. For management and operation reasons, network

operators need to check the status of IS-IS adjacencies, entries in

the routing table and the content of the IS-IS link state database.

It is obvious that, when looking at diagnostics information,

hexadecimal representations of systemIDs and LSP identifiers are less

clear than symbolic names.

One way to overcome this problem is to define a name-to-systemID

mapping on a router. This mapping can be used bidirectionally. E.g.,

to find symbolic names for systemIDs, and to find systemIDs for

symbolic names. One way to build this table of mappings is by static

definitions. Among network administrators who use IS-IS as their IGP

it is current practice to define such static mappings.

Thus every router has to maintain a table with mappings between

router names and systemIDs. These tables need to contain all names

and systemIDs of all routers in the network.

There are several ways one could build such a table. One is via

static configurations. Another scheme that could be implemented is

via DNS lookups. In this document we propose a third solution. We

hope the proposed solution is easier and more manageable than static

mapping or DNS schemes.

2. Possible solutions

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. They have to maintain this table on

each 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...