Subject: reservations versus resources, te extensions, etc..

From: Erblichs <[email-masked]>
Date: Thu, 11 Apr 2002 16:32:07 -0700

... draft-katz-yeung-ospf-traffic-06.txt

Group,
        I have a few (7) fairly fundamental questions here..

        Sorry about the lateness of this email.

        I am just trying to figure out how to support
        these extensions...

        Mitchell Erblich
        ---------------------

1)

        1a) "in this direction" used in 2.5.6 and 2.5.7,
             and not used in 2.5.8. I assume we are thinking
             from the router's interface. Since we aren't
             using this phrase in 2.5.8, is this value
             non-direction specific?

        1b)
I assume that the link atributes are direction specific
   from the perspective of a router's interface. Thus, I assume
   we can have two different values for the 2.5.6 Maximum Bandwidth.
   In the case of Ethernet, etc, should we verify that all Opaque
   speaking OSPF routers using the link "agree" on the same value?
   Especially with Ethenernet? Can one believe that the link is
   a 10Mb link and another believe it is a 100Mb link? Be neighbors,
   form an adjacency?

2)
1.2 Limitations
"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."

Given this fact. Is there a special set of events that should
occur in case both devices datagrams collide? Simply, should the
router treat retransmission of datagrams as additional consumption of
bandwidth that was reserved or as part of the original bandwidth
allocation?

3) There is no discussion on how one would be expected to
set-up reservation for example, fair-weighted queueing support.

4) Just because we reserve bandwidth in one direction (out), there is no
discussion that we will be able to forward a datagram, etc
because we have not done any input allocations. Actually,
 I don't see how we can do this input type of allocation!

5) 2.5.7 Are we to assume that oversubscription is not a problem
   because only under extreme congestion, may the lower priority
   reservations not be fulfilled? Why not state that?

6) 4.0 Compatibility issues..

        6a)  Can't the values of these opaque LSAs be used to
             determine best paths? If one network is comprised
             of a set of heterogenous routers (opaque capable and not),
             then each capable type of router could determine
             a different path. Shouldn't this lead to blackholes
             and routing loops? Couldn't a lower memory supported
             router (also less Mips capable) with opaque LSA capability
             be expected to consume more memory, more link bandwidth,
             take longer to achieve adjacencies, and possibly not
             perform as expected.

        6b) But there is no discussion, that low priority
            datagrams that overfill their output queues
            (2.5.8) due to low-reservations should even
            be dropped when the router is congested. Should
            their be primary and secondary congestion disscussions?

7) With all the discusion of bandwidth allocations, why couldn't
we support a TLV / Sub-TLV with a congestion (i.e. IS-IS overload
binary value), that would be set by the router when it is under
congestion (dropping a significant number of datagrams due to
"RED")?

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 11 Apr 2002 17:05:50 -0700

>              using this phrase in 2.5.8, is this value

Nope, unreserved bandwidth is direction specific.

>    we can have two different values for the 2.5.6 Maximum Bandwidth.

And you can have two different values of the "regular" SPF metric,
and have asymmetric routing.  You can do it, but not everyone will
be happy ....

>    speaking OSPF routers using the link "agree" on the same value?

No particular reason to do so.

> bandwidth that was reserved or as part of the original bandwidth

The issue is not datagram collision, but call admission control.

> set-up reservation for example, fair-weighted queueing support.

That's because "fair-weighted queueing" is not in the scope of this
document.  The Diff-Serv TE work comes a little bit closer.

>  I don't see how we can do this input type of allocation!

Again, not in scope.

>    reservations not be fulfilled? Why not state that?

Oversubscription is all about stat mux.  If someone can't live with
that, they shouldn't oversubscribe.

> congestion (dropping a significant number of datagrams due to

Bandwidth in the context of OSPF and IS-IS TE is all about *reservations*
not about instantaneous utilization of a link.

Kireeti.