Subject: RE: [Diffserv] Model draft - sharing elements on multiple interfa ces

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 7 Dec 2000 15:59:35 -0500

Andrew,

To your first question, I think it is important to support the ability to
aggregate multiple interfaces to a single forwarding engine since I know
many implementations that work this way. However, the question of symmetry
struck a stronger cord with me. In your alternate picture:

> -> I -+-> I -> core -> E -+-> E ->
>       |                   |
> -> I -+                   +-> E ->

It struck me that the egress is a bit more odd because I am struggling to
figure out what a fan-out on the egress means. Do you have a use case in
mind? Is this describing a possible scenario where for example a classifier
is selecting between multiple interfaces?

regards,

-Walter

> -----Original Message-----
> From: Andrew Smith [mailto:[email-masked]]
> Sent: Wednesday, December 06, 2000 1:38 PM
> To: Robert Moore
> Cc: diffserv
> 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

---

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 7 Dec 2000 17:38:19 -0500

Couldn't you satisfy this policy by making Brian's text a positive?

"[while the simple example in figure 2 does not show this explicitly] this
model allows for the sharing of elements by more than one ingress, or even
by more than one egress."

regards,

-Walter

> Sent: Thursday, December 07, 2000 3:05 PM
> To: Brian E Carpenter
> Cc: diffserv
> 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
> 
> Brian E Carpenter wrote:
> 
> > 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
> > 
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml