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

From: "Robert Moore" <[email-masked]>
Date: Tue, 5 Dec 2000 16:27:53 -0500

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

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 5 Dec 2000 14:19:33 -0800 (PST)

Bob,

I was arguing against additional complexity, which was what I believed

> > -> I -+-> I -> core -> E -+-> 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.

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 5 Dec 2000 15:38:03 -0800 (PST)

A further thought concerning the definition of StaticRowPointer.
While I think it's inappropriate for the DESCRIPTION of StaticRowPointer
to include a discussion of "cloning", nevertheless that DESCRIPTION
defines the TC's "additional semantics" as:

       The additional semantics of this textual  convention, relative
       to RowPointer, are related to the object the pointer is pointing
       to.  The  pointed-to  object  may have  more  than  one  parent
       object pointing to it, indicating the pointed-to object can be
       shared by one or more parent objects.

Now, if two data paths merge (see below), then that means that two
xxxNext pointers point to the same "pointed-to object", which by the
definition above says that the xxxNext pointers should be
StaticRowPointer's !!  That's probably not what you had in mind ??

Keith.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 10:33:40 -0600

How about covering this by a text note in the document, not by
drawing the picture.

"this model does not exclude the sharing of elements by more than
one ingress, or even by more than one egress, but this is not
explicitly modelled by the current document."

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: Andrew Smith <[email-masked]>
Date: Thu, 07 Dec 2000 12:04:54 -0800

Brian,

That almost works. We'd still have to fix up several places where it is implied 
that elements are scoped to a single interface. I think we ought only explicitly 
to include the more complex model if there are people who really want it in 
there - and I'm not hearing any public calls to do so at present.

However, if the MIB (or PIB or QDIM or ...) explicitly permits this sharing then 
I think a "does not exclude" disclaimer is not sufficient and it should be 
"included" explicitly in the Model. That is the only way to be consistent about 
a "specific standards-track instantiations may implement subsets of the Model 
but they shouldn't add new stuff" policy for this set of documents.

Andrew