IETF Logo Mail Archive

Re: Comments on draft-katz-yeung-traffic-08.txt

Sina Mirtorabi <sina@CISCO.COM> Tue, 22 October 2002 13:44 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17056 for <ospf-archive@LISTS.IETF.ORG>; Tue, 22 Oct 2002 09:44:53 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0078736A@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 9:47:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325816 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 09:47:07 -0400
Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 09:47:07 -0400
Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-9.cisco.com [144.254.54.204]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9MDl6000870 for <OSPF@DISCUSS.MICROSOFT.COM>; Tue, 22 Oct 2002 06:47:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Message-ID: <ECEBIKJEBCOMCBDBKDNBCEBLCFAA.sina@cisco.com>
Date: Tue, 22 Oct 2002 06:47:05 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Sina Mirtorabi <sina@CISCO.COM>
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <200210212314.TAA26019@bigbird.xebeo.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Rohit,

> -----Original Message-----
> From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Rohit
> Dube
> Sent: Monday, October 21, 2002 4:14 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
>
>
> Hi Sina,
>
> Just to clarify a bit more, there are two points here -
> a) Should more than 2 nodes be allowed on multi-access links or
>    not.
> b) Be clear about the decision in (a) and reflect it appropriately
>    in the document.
>
> WRT (a), I am fine with either approach but prefer the former (at max
> 2 nodes) as TE with > 2 nodes on the same multi-access links seems
> a bit un-natural when compared to the two node case. The two node
> case is well understood and known to work.

The current draft does Not prevent TE operation for having more than two
routers on multi-acess link.
I believe that the accuracy of 'reservation state' on multi-acess link Does
Not justify to disallow TE operation in case of more than two routers.

when you have a A-B-C-D path and say A-B path goes over multi-acess link,
what is un-natural if we have more than two routers attached on A-B or just
two ?
a link or segment is defined when you connect two point together, so I don't
see what is un-natural

of course as stated before, it is up to operator to maximize reservation
state in order to better reflect the number of attached router on the link.


>
> Have you (or others) implemented OSPF-TE with more than two nodes?
> Any experiences to share?


I had a chat with Robert Raszuk and I quote below his thought

--
"Yes I agree with both your & Naming's observations and comments to the
list. Today it is very often that people start to use TE without any
reservations (for one to replace LDP, for second to apply just FRR with
not reservations). Also multiaccess topologies are very common in POPs a
usual place for the TE heads. Therefor I would highly vote not to tear
any TE LSPs when two router multiaccess turns into N router one."
--


Sina

>
> --rohit.

v2.23.0 | Report a Bug | By Email