headers
Philip Christian | 3 Aug 2003 18:50
Picon
Favicon

Re: Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational

I have my own point of view, but I'm not seeing much support for it.
I wouldn't want to be the one that holds this up, not unless some other folks around 
here want to support me on the auto-encap stuff.
I don't see anything wrong with the draft as it stands.

Philip

At 0956 01/08/2003 -0700, Christian Hopps wrote
Folks,

Regarding all the proposals for making the IPv6 draft more
complex to handle mixed sets of IPv4 and IPv6, has anyone
queried operators on this issue?

When I wrote this draft I had no intention of supporting
disjoint sets of IPv4 and IPv6 routers within an area. I
specifically reference RFC 1195 [1] to handle broad issues
like this.

"In [1] a method is described to route both OSI and IPv4. We utilize
   this same method with some minor changes to allow for IPv6."

RFC 1195 was not designed to handle disjoint sets of OSI and IPv4
routers within an area either.

The draft is for the most part unchanged from 3.5 *years* ago.
It is currently implemented (and deployed) by at least 3 vendors,
and has been for a while. Interop testing has occurred. Are we being
academic here, or is there a real problem that needs solving?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Christian | 2 Aug 2003 17:52
Picon

Re: Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational

I have my own point of view, but I'm not seeing much support for it.
I wouldn't want to be the one that holds this up, not unless some other 
folks around here want to support me on the auto-encap stuff.
I don't see anything wrong with the draft as it stands.

Philip

At 09:56 01/08/2003 -0700, Christian Hopps wrote:
>Folks,
>
>Regarding all the proposals for making the IPv6 draft more
>complex to handle mixed sets of IPv4 and IPv6, has anyone
>queried operators on this issue?
>
>When I wrote this draft I had no intention of supporting
>disjoint sets of IPv4 and IPv6 routers within an area. I
>specifically reference RFC 1195 [1] to handle broad issues
>like this.
>
>"In [1] a method is described to route both OSI and IPv4. We utilize
>    this same method with some minor changes to allow for IPv6."
>
>RFC 1195 was not designed to handle disjoint sets of OSI and IPv4
>routers within an area either.
>
>The draft is for the most part unchanged from 3.5 *years* ago.
>It is currently implemented (and deployed) by at least 3 vendors,
>and has been for a while. Interop testing has occurred. Are we being
>academic here, or is there a real problem that needs solving?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pekka Savola | 4 Aug 2003 11:02
Picon

Re: Feedback on IS-IS Automatic Encapsulation

Hi,

On Sun, 27 Jul 2003 christian_tena <at> yahoo.co.uk wrote:
> Do you accept what I said about the usefulness of autoencap in SONET/SDH DCN 
> networks ?

I do not know those networks and environemtns in enough detail to comment 
for certainty, but their characteristics seemed to be slightly different 
than those of a typical Internet network.

> On 20 Jul 2003 at 1:13, Philip Christian wrote:
> 
> > I always felt that automatic encapsulation might be of
> > less practical use in the Internet 
> > than in the context in which it was thought of, and
> > that is in SDH/SONET DCN 
> > networks.
> > 
> > Most Internet routers (more probably all) are
> > reasonably easily upgradable, and 
> > operators probably don't mind taking a router out of
> > service for a while in order to 
> > upgrade it to IPv6.  The only slight problem that they
> > have is that because of IS-IS 
> > topological restrictions they shouldn't really forward
> > any IPv6 traffic in the level-1 area or 
> > level-2 subdomain until all of the routers have been
> > upgraded, unless they use 
> > something like MT.
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 4 Aug 2003 16:14
Picon
Favicon

I-D ACTION:draft-ietf-isis-traffic-05.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		: IS-IS extensions for Traffic Engineering
	Author(s)	: T. Li, H. Smit
	Filename	: draft-ietf-isis-traffic-05.txt
	Pages		: 13
	Date		: 2003-8-4
	
This document describes extensions to the IS-IS protocol to support
Traffic Engineering.
This document extends the IS-IS protocol by specifying new
information that an Intermediate System [router] can place in Link
State Protocol Data Units.  This information describes additional
details of the state of the network that are useful for traffic
engineering computations.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-traffic-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Przygienda | 11 Aug 2003 10:52

ISIS meeting minutes ..

Pls whoever took ISIS meeting minutes in Vienna, fwd to me for further
processing ...

    thanks

    -- tony
Permalink | Reply | 0 comments |
headers
Tony Przygienda | 14 Aug 2003 23:24

interesting draft ...


Interesting for all the people looking for msec convergence

    -- tony

------------------------------------------------------------------------

This is a forwarded message
From: Alex Zinin <zinin <at> psg.com>
To: Routing Area Mailing List <routing-discussion <at> ietf.org>
Cc: grow <at> lists.uoregon.edu
Date: Wednesday, August 13, 2003, 5:17:55 PM
Subject: Mailing list for BFD

===8<==============Original message text===============
Folks-

 In order to continue the discussion on draft-katz-ward-bfd in
 an organized fashion, the following mailing list has been
 established:

   List name    : rtg-bfd <at> ietf.org
   List URL     : https://www1.ietf.org/mailman/listinfo/rtg-bfd
   To subscribe : URL above or rtg-bfd-request <at> ietf.org

 Interested participants are encouraged to subscribed to the list.

-- Alex http://www.psg.com/~zinin/
Permalink | Reply | 0 comments |
headers
The IESG | 26 Aug 2003 22:55
Picon
Favicon

Document Action: 'IS-IS extensions for Traffic Engineering' to Informational RFC

The IESG has approved the Internet-Draft 'IS-IS extensions for Traffic 
Engineering' <draft-ietf-isis-traffic-05.txt> as an Informational RFC. This 
document is the product of the IS-IS for IP Internets Working Group. 

The IESG contact persons are Alex Zinin and Bill Fenner.

RFC Editor's Note:

Section 3.7 "Sub-TLV 18: Traffic Engineering Default metric"
Second para:

    OLD:

      To preclude overflow within a SPF implementation, all metrics greater
      than or equal to MAX_PATH_METRIC SHALL be considered to have a metric
      of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such
      that MAX_PATH_METRIC plus a single link metric does not overflow the
      number of bits for internal metric calculation. We assume that this
      is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32
      - 2^25).

    NEW:

      To preclude overflow within a a traffic engineering SPF implementation,
      all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered
      to have a metric of MAX_PATH_METRIC. It is easiest to select
      MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does
      not overflow the number of bits for internal metric calculation. We
      assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to
      be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane