headers
Internet-Drafts | 4 Oct 2007 16:30
Picon
Favicon

I-D Action:draft-ietf-isis-rfc2763bis-00.txt

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           : Dynamic Hostname Exchange Mechanism for IS-IS
	Author(s)       : D. McPherson, N. Shen
	Filename        : draft-ietf-isis-rfc2763bis-00.txt
	Pages           : 7
	Date            : 2007-09-30

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-systemID mapping information across the IS-IS network.

The intention of this document is to provide an update to [RFC 2763].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc2763bis-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org 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-rfc2763bis-00.txt".
(Continue reading)

Permalink | Reply | 2 comments |
headers
Parker, Jeff | 5 Oct 2007 14:51
Favicon

FW: I-D Action:draft-ietf-isis-rfc2763bis-00.txt

I am sure that there is something new in the draft, but I have missed it. 
How does this draft extend RFC 2763?  The TLV and encoding seem unchanged.

- jeff parker 

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: Thu 10/4/2007 10:30 AM
To: i-d-announce <at> ietf.org
Cc: isis-wg <at> ietf.org
Subject: [Isis-wg] I-D Action:draft-ietf-isis-rfc2763bis-00.txt 

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           : Dynamic Hostname Exchange Mechanism for IS-IS
	Author(s)       : D. McPherson, N. Shen
	Filename        : draft-ietf-isis-rfc2763bis-00.txt
	Pages           : 7
	Date            : 2007-09-30

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-systemID mapping information across the IS-IS network.

The intention of this document is to provide an update to [RFC 2763].
Permalink | Reply | 1 comment |
headers
IETF I-D Submission Tool | 5 Oct 2007 17:25
Picon
Favicon

New Version Notification for draft-ietf-isis-ipv6-07


A new version of I-D, draft-ietf-isis-ipv6-07.txt has been successfuly submitted by Christian Hopps and
posted to the IETF repository.

Filename:	 draft-ietf-isis-ipv6
Revision:	 07
Title:		 Routing IPv6 with IS-IS
Creation_date:	 2007-10-04
WG ID:		 isis
Number_of_pages: 6

Abstract:
This draft specifies a method for exchanging IPv6 routing information
using the IS-IS routing protocol.  The described method utilizes 2
new TLVs, a reachability TLV and an interface address TLV to
distribute the necessary IPv6 information throughout a routing
domain.  Using this method one can route IPv6 along with IPv4 and OSI
using a single intra-domain routing protocol.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

The IETF Secretariat.
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 Oct 2007 17:30
Picon
Favicon

I-D Action:draft-ietf-isis-ipv6-07.txt

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           : Routing IPv6 with IS-IS
	Author(s)       : C. Hopps
	Filename        : draft-ietf-isis-ipv6-07.txt
	Pages           : 6
	Date            : 2007-10-05

This draft specifies a method for exchanging IPv6 routing information
using the IS-IS routing protocol.  The described method utilizes 2
new TLVs, a reachability TLV and an interface address TLV to
distribute the necessary IPv6 information throughout a routing
domain.  Using this method one can route IPv6 along with IPv4 and OSI
using a single intra-domain routing protocol.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-07.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
IETF I-D Submission Tool | 4 Oct 2007 16:23
Picon
Favicon

New Version Notification for draft-ietf-isis-rfc2763bis-00


A new version of I-D, draft-ietf-isis-rfc2763bis-00.txt has been successfuly submitted by Danny
McPherson and posted to the IETF repository.

Filename:	 draft-ietf-isis-rfc2763bis
Revision:	 00
Title:		 Dynamic Hostname Exchange Mechanism for IS-IS
Creation_date:	 2007-09-30
WG ID:		 isis
Number_of_pages: 7

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-systemID mapping information across the IS-IS network.

The intention of this document is to provide an update to [RFC 2763].

The IETF Secretariat.
Permalink | Reply | 0 comments |
headers
Christian Hopps | 5 Oct 2007 17:29

Re: I-D Action:draft-ietf-isis-rfc2763bis-00.txt

This is part of the move things from informational to proposed  
standard. There should in fact be no substantive changes.

Chris.

On Oct 5, 2007, at 5:51 AM, Parker, Jeff wrote:

> I am sure that there is something new in the draft, but I have  
> missed it.
> How does this draft extend RFC 2763?  The TLV and encoding seem  
> unchanged.
>
> - jeff parker
>
>
> -----Original Message-----
> From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
> Sent: Thu 10/4/2007 10:30 AM
> To: i-d-announce <at> ietf.org
> Cc: isis-wg <at> ietf.org
> Subject: [Isis-wg] I-D Action:draft-ietf-isis-rfc2763bis-00.txt
>
> 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           : Dynamic Hostname Exchange Mechanism for IS-IS
> 	Author(s)       : D. McPherson, N. Shen
(Continue reading)

Permalink | Reply | 0 comments |
headers
Theodore.Wang | 14 Oct 2007 13:14

Question about Purge LSP in RFC 1142

Hi, all
 
I have a question about Purge LSP in RFC 1142.
In RFC 1142, I find the following lines:
 
e)An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax shall
1)log a circuit notification, corruptedLSPReceived,
2)overwrite the Checksum and Remaining Lifetime with 0, and
3)treat the Link State PDU as though its Remaining Lifetime had expired
These lines define the way how to cope with the LSP with incorrect checksum, that is to flood the LSP's header with zero remaining lifetime.
 
But in fact, in a huge network, it is hard to locate the router that generate the Purge LSP, and which is the situation I'm facing. A Corrupted LSP Storm is happening in the network and it lacks a efficient way to troubleshooting because we can only use "ignore checksum error" on every router to find the one that flooded the Purge LSP.
 
Therefore, is it possible to attach a new TLV in Purge LSP that defines the originator?
 
Thanks in advance!
_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
Permalink | Reply | 6 comments |
headers
mike shand | 19 Oct 2007 13:34
Picon
Favicon

Re: Question about Purge LSP in RFC 1142

Theodore.Wang wrote:
Hi, all
 
I have a question about Purge LSP in RFC 1142.
In RFC 1142, I find the following lines:
You should not be paying any attention to RFC 1142. It is a copy of DP 10589 which is a version of ISO/IEC 10589 several stages before its final standardisation and differs from ISO/IEC 10589 is several important respects.

If you want to know what the standard says, get a copy of ISO/IEC 10589:2002 from

http://standards.iso.org/ittf/PubliclyAvailableStandards/




 
e)An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax shall
1)log a circuit notification, corruptedLSPReceived,
2)overwrite the Checksum and Remaining Lifetime with 0, and
3)treat the Link State PDU as though its Remaining Lifetime had expired
These lines define the way how to cope with the LSP with incorrect checksum, that is to flood the LSP's header with zero remaining lifetime.

In fact this behaviour has been changed in the second edition and now reads

e) An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax shall
1) generate a corruptedLSPReceived circuit event,
2) discard the PDU.

see also RFC 3719 section 8, which reads

8.  Purging Corrupted PDUs

   While ISO 10589 requires in section 7.3.14.2 e) that any LSP received
   with an invalid PDU checksum should be purged, this has been found to
   be disruptive.  Most implementations today follow the revised
   specification, and simply drop the LSP.

   In ISO 10589:2002 [1], Section 7.3.14.2, it states:

      (e)  An Intermediate system receiving a Link State PDU with an
           incorrect LSP Checksum or with an invalid PDU syntax SHOULD

           1) generate a corruptedLSPReceived circuit event,

           2) discard the PDU.


 
But in fact, in a huge network, it is hard to locate the router that generate the Purge LSP, and which is the situation I'm facing. A Corrupted LSP Storm is happening in the network and it lacks a efficient way to troubleshooting because we can only use "ignore checksum error" on every router to find the one that flooded the Purge LSP.
It is for this reason (the purge storm) that the specification was changed!
 
Therefore, is it possible to attach a new TLV in Purge LSP that defines the originator?
No.
 
Thanks in advance!
_______________________________________________ Isis-wg mailing list Isis-wg <at> ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg 

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
Permalink | Reply | 1 comment |
headers
Manav Bhatia | 19 Oct 2007 13:57
Picon
Favicon
Gravatar

RE: Question about Purge LSP in RFC 1142

Hi Wang,
 
Most implementations would just drop the corrupted LSPs - the problem you describe wouldn't occur if you did this.
 
Cheers,
Manav

From: Theodore.Wang [mailto:theodore.wang <at> gmail.com]
Sent: Sunday, October 14, 2007 4.44 PM
To: isis-wg <at> ietf.org
Subject: [Isis-wg] Question about Purge LSP in RFC 1142

Hi, all
 
I have a question about Purge LSP in RFC 1142.
In RFC 1142, I find the following lines:
 
e)An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax shall
1)log a circuit notification, corruptedLSPReceived,
2)overwrite the Checksum and Remaining Lifetime with 0, and
3)treat the Link State PDU as though its Remaining Lifetime had expired
These lines define the way how to cope with the LSP with incorrect checksum, that is to flood the LSP's header with zero remaining lifetime.
 
But in fact, in a huge network, it is hard to locate the router that generate the Purge LSP, and which is the situation I'm facing. A Corrupted LSP Storm is happening in the network and it lacks a efficient way to troubleshooting because we can only use "ignore checksum error" on every router to find the one that flooded the Purge LSP.
 
Therefore, is it possible to attach a new TLV in Purge LSP that defines the originator?
 
Thanks in advance!
_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
Permalink | Reply | 0 comments |
headers
Dave Katz | 19 Oct 2007 16:32
Favicon

Re: Question about Purge LSP in RFC 1142


On Oct 19, 2007, at 5:34 AM, mike shand wrote:

>
>>
>> But in fact, in a huge network, it is hard to locate the router  
>> that generate the Purge LSP, and which is the situation I'm  
>> facing. A Corrupted LSP Storm is happening in the network and it  
>> lacks a efficient way to troubleshooting because we can only use  
>> "ignore checksum error" on every router to find the one that  
>> flooded the Purge LSP.
> It is for this reason (the purge storm) that the specification was  
> changed!

Yep.  There was a busted UUnet link in Texas, I believe, back in  
around '96, that was corrupting packets but delivering them with  
valid datalink checksums.  This caused every LSP crossing the link  
(which is, by definition, eventually *every* LSP) to be purged and  
reflooded.  And purged and reflooded.  It was quite spectacular, if  
rather unpleasant.  I don't quite remember how we found the bad  
link;  probably saw some other error indications at the ends.  A knob  
was added rather quickly.

--Dave
Permalink | Reply | 0 comments |

Gmane