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

Rohit Dube <rohit@XEBEO.COM> Mon, 21 October 2002 22:15 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 SAA17140 for <ospf-archive@LISTS.IETF.ORG>; Mon, 21 Oct 2002 18:15:34 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00785805@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 18:17:48 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323015 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 18:17:48 -0400
Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 18:17:48 -0400
Received: (qmail 19341 invoked from network); 21 Oct 2002 22:17:47 -0000
Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 21 Oct 2002 22:17:47 -0000
Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id SAA11690 for <OSPF@DISCUSS.MICROSOFT.COM>; Mon, 21 Oct 2002 18:17:47 -0400
X-Mailer: exmh version 2.1.1 10/15/1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <200210212217.SAA11690@bigbird.xebeo.com>
Date: Mon, 21 Oct 2002 18:17:47 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Rohit Dube <rohit@XEBEO.COM>
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: Message from Sina Mirtorabi <sina@CISCO.COM> of "Mon, 21 Oct 2002 11:26:43 PDT." <ECEBIKJEBCOMCBDBKDNBMEPECEAA.sina@cisco.com>
Precedence: list

Hi Sina,

Some comments inline [..]

On Mon, 21 Oct 2002 11:26:43 -0700 Sina Mirtorabi writes:
=>Rohit,
=>
=>> -----Original Message-----
=>> From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Rohit
=>> Dube
=>> Sent: Saturday, October 19, 2002 11:02 AM
=>> To: OSPF@DISCUSS.MICROSOFT.COM
=>> Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
=>>
=>>
=>> Hello Naiming,
=>>
=>> Thanks for your thoughtful comments. There are two ways one can
=>> look at TE over multi-access links -
=>>
=>> a) Only 2 devices are allowed. This was my interpretation based
=>>    on section 1.2. My take is that if the condition is violated
=>>    (ie there are more than 2 devices) one needs to spell out
=>>    how to react to this.
=>
=>this is not how I would interpret.
=>section 1.2 of the draft states:
=>
=>"The extensions specified in this document capture the reservation state of
=>point-to-point links. The reservation state of multiaccess links is not
=>accurately _reflected_, except in the special case that there are only two
=>devices in the multiaccess subnetwork."

Fair enough. However when I read the draft the first time, my conclusion
was "since reservation state is not accurately reflected for more than two
nodes, it would be dangerous to use more than two nodes on a multi-access
networl". Some other folks that I know interpreted it similarly.

=>
=>
=>> b) More than 2 devices are allowed which can work given the
=>>    limitations you list below. If this is allowed, we need
=>>    to explicitly say so and indicate any additional procedures
=>>    in the draft.
=>>
=>
=>yes this is how I would read the draft...
=>as far as for additional procedure, what else is needed to define a TE over
=>multi-acess link having more than two attached routers? ( given the
=>limitation for reservation state )
=>
=>since 'Maximum Reservable Bandwidth' is configurable it is up to the
=>operator to set a value that reflect a bit better the number of routers
=>attached to the multi-acess network for example if there are N routers
=>attached and we do not want to oversubscribe one could set
=>
=>Maximum Reservable Bandwidth <= Maximum Bandwidth / ( N-1 )
=>where N is the number of routers attached to multi-acess link
[snip]

This will not require defining anything new, but it does require
being a bit more verbose in dealing with multi-access networks.
If the draft says nothing more, some implementors will likely force two
nodes and others will allow more than two. The two types of implementations
in the same network will provide surprising and undocumented results.
Adding a small section on the topic is a small price to pay to avoid such
problems down the road.


Regards,
--rohit.