Subject: Re: [Diffserv] Model draft - sharing elements on multiple interfaces

From: "Robert Moore" <[email-masked]>
Date: Fri, 8 Dec 2000 09:36:41 -0500

Andrew,

OK, I like this picture a lot better than I liked mine.  It does
raise a question, though.  What's the direction for those three
interfaces that sit between the routing cores?  Intuitively,
they're egress from the point of view of "Routing Core", and
ingress from the point of view of "Another Routing Core."
So what do we call them?

The question becomes harder when we look at the MIB.  The
diffServDataPathTable has two indexes:  ifIndex and
diffServDataPathIfDirection.  For a given ifIndex, you're going
to use up the two Direction values for the "real" ingress path
on the interface (not shown in your picture), and for the
egress path shown at the right in your picture.  The only way
out that I see is to define a third "direction," something like
coreToCore, to identify the data paths in the middle of your
picture.  I recognize that this would be a fairly significant
change to the model.  But without it, I think you will have a
picture of a configuration that the MIB is incapable of
representing.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

Andrew Smith <[email-masked]> on 12/07/2000 02:43:09 PM

To:   Robert Moore/Raleigh/IBM@IBMUS
cc:   diffserv <[email-masked]>
Subject:  Re: [Diffserv] Model draft - sharing elements on multiple
      interfaces

Bob,

Without diving into the details for now, can we agree that, if the "ingress
SLS
shared over multiple interfaces" idea is interesting, then so is the
*egress*
one? Seems like some operations folks out there might be very interested in
this
.... no? (think: multi-tenant buildings, metro services?)

Now diving into the details, the egress picture I would draw would be more
like:

  +---------+                   +----------+
  |         |i/f 1---\          |          |--> i/f 1
  |         |         \         |Another   |
  |Routing  |i/f 2----->meter-->|Routing   |--> i/f 2
  |Core     |         /         |Core      |
  |         |i/f 3---/          |          |--> i/f 3
  +---------+                   +----------+

It is of no business to the Diffserv elements how the traffic gets split
back
out to the interfaces on the r.h.s. so it is appropriate to model that
function
as a black box (in this Model document). A "Classifier" at that point is
not the
right functional block to perform the routing functions (which may be as
simple
as "do the same thing as the prior Routing Core did" - it's not our
business to
describe how it might do that).

Andrew

Robert Moore wrote:

> Andrew,
>
> I'm still having trouble with the egress half of your
> symmetric solution.  Here's how I visualize your idea
> of metering aggregated traffic across a set of egress
> interfaces:
>
> +---------+                   +----------+
> |         |i/f 1---\          |          |--> i/f 1
> |         |         \         |          |
> |Routing  |i/f 2----->meter-->|classifier|--> i/f 2
> |Core     |         /         |          |
> |         |i/f 3---/          |          |--> i/f 3
> +---------+                   +----------+
>
> In words, the Routing Core does whatever it does to
> route packets (which is *outside* the scope of
> DiffServ), and for each packet selects egress i/f
> 1, 2, or 3.  The data paths for these three egress
> interfaces then merge into a single meter, to
> provide the metering for the aggregated traffic.
> The meter is followed by a classifier, which fans
> the packets back out to their respective interfaces
> for queueing, scheduling, etc.
>
> It's the classifier that I don't understand.  If the
> Routing Core selects an egress interface for a packet
> based on routing criteria that are outside the scope of
> DiffServ, then how can the classifier get each packet
> back to the correct interface?  What is it filtering
> on?  It can't base its decision on which interface
> the packet traversed just before the meter, because
> the model stipulates that a packet doesn't "remember"
> where it has been.
>
> Do you have a different way of thinking about this
> situation, one that doesn't run into this problem?
>
> Regards,
> Bob
>
> Bob Moore
> IBM Networking Software
> +1-919-254-4436
> [email-masked]
>
>
>
> Andrew Smith <[email-masked]> on 12/06/2000 01:38:08 PM
>
> To:   Robert Moore/Raleigh/IBM@IBMUS
> cc:   diffserv <[email-masked]>
> Subject:  Re: [Diffserv] Model draft - sharing elements on multiple
>       interfaces
>
>
>
> Bob,
>
> I think you're trying to craft a compromise with Keith here but what you
> propose
> is inconsistent. [Note that I didn't mention the MIB in my message: the
MIB
> can
> implement a subset of the model if it so chooses, so long as it is not
> inconsistent with the model, but that's not the point I raised - by all
> means
> discuss the impact of this issue on the MIB in a separate thread but
don't
> let
> that confuse this discussion of the model].
>
> The point in question is whether "shared-between-multiple-interfaces"
> elements
> are both (a) useful for implementing specific services and (b) likely to
be
> implemented by more than one vendor and (c) without this change, does it
> make it
> impossible/unlikely that the model can be used to represent a significant
> set of
> devices? I believe that, for (a), the model needs to be symmetric: if
such
> a
> service is useful for "in" then it is also for "out" e.g. metering on a
> collection of interfaces representing one customer is just as useful in
> both
> directions. As regards (b), I'd like to hear some more opinions: so far
the
> exit
> poll (3 opinions) seems to read:
>
>    In?   Out?
>    Y/N   Y/N
>    2/1   1/2
>
> (if that notation makes sense). And for (c) I'm not sure we have any data
> points.
>
>
> Andrew
>
>
> Robert Moore wrote:
>
>
>> Keith,
>>
>> If I'm understanding you correctly, then I think I agree
>> with you.  We can allow the sharing of conditioning
>> elements in the ingress case, but continue to rule it out
>> for egress.  This covers a case like a single meter that
>> processes traffic aggregated from several ingress
>> interfaces, which seems like something we want to allow.
>> But it doesn't complicate the MIB in the egress case.
>>
>> If we allow sharing of conditioning elements for ingress
>> interfaces, I think there are two cases that need to be
>> mentioned in the MIB:
>>
>>   - Two DataPathStart pointers pointing to the same
>>     element.  If we leave it at that, we have no answer
>>     to the question "Which data path is the element
>>     *really* on?"  But I think this is OK -- we can
>>     say that it's equally on both data paths.
>>   - A "next" pointer in a conditioning element pointing
>>     to a next conditioning element on a different
>>     data path.
>>
>> The MIB would also have to say clearly that these two
>> options are *not* allowed for egress data paths.
>>
>> For Andrew's picture, I think it would be fine to
>> combine the new version for the ingress side with the
>> old version for the egress side.
>>
>> Does this sound good to everybody?
>>
>> Regards,
>> Bob
>>
>> Bob Moore
>> IBM Networking Software
>> +1-919-254-4436
>> [email-masked]
>>
>>
>>
>> Keith McCloghrie <[email-masked]>@ietf.org on 12/05/2000 05:19:33 PM
>>
>> Sent by:  [email-masked]
>>
>>
>> To:   Robert Moore/Raleigh/IBM@IBMUS
>> cc:   [email-masked] (Keith McCloghrie), [email-masked]
>
> (Andrew
>
>>       Smith), [email-masked] (diffserv)
>> Subject:  Re: [Diffserv] Model draft - sharing elements on multiple
>>       interfaces
>>
>>
>>
>> Bob,
>>
>> I was arguing against additional complexity, which was what I believed
>> would ensue from Andrew's proposed change from:
>>
>>
>>
>>>> -> I -> core -> E ->
>>>>
>>>> The proposal would be to modify this to something like:
>>>>
>>>> -> I -+-> I -> core -> E -+-> E ->
>>>>        |                   |
>>>> -> I -+                   +-> E ->
>>>
>> I think it would be possible to allow merging on ingress just by
>> removing the restriction on two data paths merging, which is stated
>> in this ASN.1 comment (I think that's the only place it's specified):
>>
>>   -- The use of next pointer to point to diffserv functional datapath
>>   -- element of a different datapath is not allowed
>>
>> I agree it's harder for egress which requries splitting, for which
>> I think the current MIB structure is insufficient, and my concern is
>> that a MIB structure which would allow it is going to be more complex.
>>
>> Keith.
>>
>>
>>
>>
>>> Keith,
>>>
>>> I'm not sure what you're arguing for here.  At least
>>> on the ingress side, sharing an element (say a
>>> Classifier) between two ingress interfaces amounts
>>> to having the dataPathStart pointers for two entries
>>> in the dataPathTable point to the same entry in the
>>> diffServClassifier table.  Are you saying that the MIB
>>> currently rules this out?  If so, I've missed it.  Or
>>> are you saying that while the MIB doesn't currently
>>> rule it out, it should be changed so that it does?
>>>
>>> It's a little harder to describe for egress, but I
>>> think the idea would be that two Data Paths start out
>>> together, but then somehow diverge before they're done.
>>> I'm not sure exactly how to express this in terms of
>>> the Next pointers, but the same question I asked you
>>> above applies here as well:  do you think that the MIB
>>> currently does outlaw this setup, or do you think that
>>> it should (but doesn't now)?
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Bob
>>>
>>> Bob Moore
>>> IBM Networking Software
>>> +1-919-254-4436
>>> [email-masked]
>>>
>>>

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Andrew Smith <[email-masked]>
Date: Fri, 08 Dec 2000 17:37:54 -0800

Bob,

> ingress from the point of view of "Another Routing Core."

I don't actually think the "direction" property is that interesting: the binary 
in/out choice was OK before but it was really just a descriptive flag, rather 
than anything very fundamental.

> change to the model. 

I don't think that is a very significant change for the Model (see above). The 
more significant change is to acknowledge that such multi-stage structures might 
be useful for services built on devices that implement this Model. Still waiting 
for some opinions on whether that is a change for the better or not.

> But without it, I think you will have a

Something about carts and horses comes to mind .....

> ..... no? (think: multi-tenant buildings, metro services?)
>