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

From: "Robert Moore" <[email-masked]>
Date: Wed, 6 Dec 2000 11:42:04 -0500

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]
>
>
>
> Keith McCloghrie <[email-masked]> on 12/05/2000 03:54:50 PM
>
> To:   [email-masked] (Andrew Smith)
> cc:   [email-masked] (diffserv), Robert Moore/Raleigh/IBM@IBMUS
> Subject:  Re: [Diffserv] Model draft - sharing elements on multiple
>       interfaces
>
>
>
> I think the DiffServ MIB is only just use-able at the moment due to
> its surfeit of complexity, and I suggest that incorporating the below
> into the model and thus reflecting it into the MIB will push the MIB
> over the "cliff" to become of no use to anybody.
>
> Keith.
>
> > This is a proposal for a solution to the second issue in my earlier
> message
> > Ref:
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt
> >
> > 2. Sharing of elements amongst multiple interfaces.
> >
> > Bob Moore has made a good point: right now the model describes
everything
> that
> > happens to a packet as it arrives on ingress to *an* interface, then it
> goes
> > through a routing core, then it describes what happens on egress from
> *an*
> > interface. The problem is that there are very valid scenarios (and
> > implementation architectures too, although that's not really our
problem
> here)
> > where you want traffic streams from multiple ingress interfaces to
> receive
> > shared processing before they get to the switch fabric. Ditto for a
> stream on
> > egress to receive some diffserv processing before being split out to
its
> final
> > egress interface. This is a fairly fundamental ommission and I don't
> think it
> > can be tackled by hand-waving. So we should choose whether to support
it
> > explicitly or not.
> >
> > To support it, I think we need a modified top-level diagram that shows
> that you
> > may repeat the routing core and subsequent "interface" blocks multiple
> times.
> > The current figure 2 implies that you may have only one "ingress
> interface
> > block" and one "egress interface block" per interface (the blocks are
the
> dotted
> > boxes in the figure). I believe we would need an additional "routing
> core" of
> > some sort in between the first per-interface block and any subsequent
> > shared-multi-interface block in order to express the interconnections
> (similar
> > for egress). Do we then need arbitrary concatenations of such blocks or
> does 2
> > on ingress and 2 on egress of each suffice?
> >
> > I'm too lazy to draw the real picture right now (a real ASCII-art
> challenge to
> > do it in only 72 columns) but it's something like this: right now we
have
> one
> > direction, the top half, of figure 2 as:
> >
> > -> I -> core -> E ->
> >
> > The proposal would be to modify this to something like:
> >
> > -> I -+-> I -> core -> E -+-> E ->
> >        |                   |
> > -> I -+                   +-> E ->
> >
> > Where "I" represents an Ingress block and "E" represents an Egress
block.
> And
> > you could represent the merge/split functions as additional routing
cores
> > (albeit simplified ones, still out of scope for this model: maybe this
> would be
> > a use for those under-utilised Multiplexor and Demultiplexor elements
but
> they'd
> > have to be redefined so that their scope could span multiple interfaces
-
> right
> > now all elements are implicitly instantiated per-interface in this
> model).
> >
> > [I don't know if this solves Bob's issue or not - hopefully he'll let
us
> know.]
> >
> > Andrew Smith
> > (editor of this draft)
> >
> >
> > _______________________________________________
> > 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: Wed, 06 Dec 2000 10:38:08 -0800

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