The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00395



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[Diffserv] RFC2597

  • From: Eyad Saheb <esaheb@hyperchip.com>
  • Date: Tue, 24 Oct 2000 14:16:31 -0400
  • Cc: "'mpls@UU.NET'" <mpls@UU.NET>

Title: RE: [Diffserv] RFC2597

I concur with Kathleen.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kathleen
Nichols
Sent: Tuesday, October 24, 2000 1:50 PM
Cc: diffserv@ietf.org; mpls@UU.NET
Subject: Re: [Diffserv] RFC2597



Chatur sharp wrote:
>
...
>
> Anyhow phrases like :
> "  The EF traffic SHOULD receive this rate
>    independent of the intensity of any other traffic
>    attempting to transit the node.  "
>
> Do not make any sense, till the time you specify what
> is the meaning of transit.

The meaning of transit (from www.dictionary.com):

tran·sit (trnst, -zt)
 n. Abbr. t.

        1.The act of passing over, across, or through; passage.
        2.Conveyance of people or goods from one place to another,
especially on a local public transportation system.
        3.A transition or change, as to a spiritual existence at death.
        4.Astronomy.
             a.The passage of a celestial body across the observer's
meridian.
             b.The passage of a smaller celestial body or its shadow
across the disk of a larger celestial body.
        5.A surveying instrument similar to a theodolite that measures
horizontal and vertical angles.

Definition 1 is what we had in mind. I would have thought the others
didn't fit.

> Does it mean that traffic
> coming on interface i and going out of interface j
> will have this commitment?

It is difficult to tell if you mean by the above: "coming
in on a specific interface i and going out of a specific
interface j" or "coming in on some arbitrary interface i
and going out on some arbitrary interface j".

>
> IMHO, DIFFSERV should provide an option to let
> PHBs be associated to destination addresses or egress
> points through a network if needed. It will still
> allow
> diffserv to work in the manner it is working today and
>
> will also enable SPs to provide garuntees which are
> required by some of the real-time applications
>

Again, it is difficult to tell if you mean "associating"
in the sense of applying a classifier on that destination
address and when there is a match, treating it with that
PHB (which is, of course, possible) of if you mean you
want to specifically take all the packets marked for a particular
per-node forwarding behavior and ensure that they egress the
network at a particular point. This is clearly something in
the domain of the control plane, not the forwarding path and
would require that the IGP make a decision based on the DSCP
it seems. This is the wrong working group for that.

> Finally, I think the DIFFSERV-MPLS approach is
> the right approach as it really takes into account
> need of all kinds of traffic rather than just the
> traditional IP services.

Then it sounds like your needs are being met. MPLS is a control
plane approach using diffserv mechanisms in the FP. If you like
that approach, it isn't clear what you want this WG to do.


        Kathie