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

From: "Robert Moore" <[email-masked]>
Date: Sun, 10 Dec 2000 07:58:58 -0500

Hi Andrew,

There are carts and horses, but there are also dogs and tails.
I think that the IETF's concept of an interface, in part as
formalized in the Interfaces MIB, is more fundamental than all
of DiffServ.  If you can incorporate your DiffServ-in-the-middle
function into the concept of an interface without doing violence
to the concept of an interface, then that's great.  If not,
though, then I think the concept of interface is the dog, and
DiffServ (in Toto (sorry -- couldn't resist the dog pun:-):
existing RFCs, Informal Model, MIB, PIB) is the tail.

In other words, if you think we need to represent DiffServ data
paths that cross "interfaces" on the egress side, then we may
need to say that DiffServ can happen in two places in a system:
on an ingress or egress interface, and in a component that sits
between routing cores, but is not an interface.  I believe that
the only reason you're saying now that this location in the
middle is an interface is that we previously, before you
considered this case, you had placed all DiffServ functions on
interfaces.

This change would ripple painfully through much of the Informal
Model  and the MIB & PIB, so let me be clear that I'm not
proposing it.  As I said earlier, I would be satisfied if we
had cross-interface data paths only on ingress.  Nor am I
saying that the interface dog absolutely cannot accommodate the
DiffServ--in-the-middle tail you've suggested.  I *am* saying,
however, that we'd better make sure that the people who work
with the concept of an interfaces in other contexts understand
what we're doing, and agree that it's appropriate, before we
move forward with your proposal.

Regards,
Bob

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

Andrew Smith <[email-masked]>@ietf.org on 12/08/2000 08:37:54
PM

Sent by:  [email-masked]

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

Bob,

Robert Moore wrote:

> 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?

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.

> 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.

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
> picture of a configuration that the MIB is incapable of
> representing.

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

> 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

_______________________________________________
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

_______________________________________________
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: Sun, 10 Dec 2000 20:38:05 -0800

Bob,

Well, my earlier comment about the "in" and "out" spigot things in Diffserv MIB 
being more like "rmonDataSource" than "ifIndex" things wasn't entirely 
facetious. The "IETF concept of an interface, in part as formalized in the 
Interfaces MIB" has its uses but I don't think it can be said to be the 
normative definition of an interface for non-MIB things.

But I only proposed this change to the Model in order to try to satisfy the 
issue that you yourself raised regarding functional elements that were to be 
applied to more than interface. If we add it for the ingress side then we must 
also add it for the egress. If you don't think it needs to be added then let's 
leave it out. However, the MIB *must* not then allow the concept to sneak in 
through the back door - the whole purpose of the Model is to set the boundaries 
on what the MIB/PIB/etc. can represent.

Andrew