Subject: Re: [Diffserv] DS boundary router's default behavior

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Dec 1999 09:59:55 -0600

I'm hopeful that there will be a diffserv implementors' list very soon.
That would be a good place for such a discussion, which is more part of
developing "best practice" than it is standards work.

   Brian

"Yoram Bernet (Exchange)" wrote:
> 
> > Brian,
> >
> > After posting the default behavior question, I didn't get a
> > response to
> > address the issue (except your reply). So, I am not sure the
> > question should
> > belong to which one: "don't care", "don't think about" or
> > "shouldn't discuss
> > in this list".
> 
> Actually, I did reply. My mail is reattached. I do think that this is
> something that should be discussed. I'm not sure that it's going to get much
> traction in this WG.
> >
> > Because I think this issue is so fundamental for any public
> > ISP to deploy
> > DiffServ, I hope there are some discussion about this. Do you
> > think this
> > issue should be in the DS WG scope? If not, where it should
> > be? I heard some
> > deployment of DiffServ, do you know how they consider about
> > this issue?
> > Thanks for your input.
> >
> 
> I know that there is a proposal for some discussion regarding the behaviour
> configuration and policy controlled behaviour of such edge devices in the
> RAP WG.
> 
> > Regards,
> >
> > Yang
> >
> > -----Original Message-----
> > From: Wang, Yang [mailto:[email-masked]]
> > Sent: Tuesday, December 07, 1999 2:49 PM
> > To: 'Brian E Carpenter'; Wang, Yang
> > Cc: [email-masked]
> > Subject: RE: [Diffserv] DS boundary router's default behavior
> >
> >
> > Brian,
> >
> > Thanks. I expect the NO answer too since I read most docs and
> > cannot find
> > it.
> >
> > This question is related to the security issue RFC 2475 has discussed
> > (theft- and denial-of-service). In order to protect the
> > resources at core,
> > it requires the DS boundary nodes to do the conditioning and
> > authentication
> > for the incoming traffic. Also, this boundary should be in the first
> > aggregation layer of the edge. For a large public network, there are
> > thousands of DS boundary nodes located in different access points
> > (dedicated, DSL, Wireless, Dial-up, etc) with different
> > vendor products. If
> > we don't have a standard default behavior (or default
> > protecting behavior)
> > for all DS boundary routers, it is very difficult to deploy
> > without breaking
> > the security.
> >
> > Thanks,
> >
> > Yang
> >
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:[email-masked]]
> > Sent: Tuesday, December 07, 1999 11:26 AM
> > To: Wang, Yang
> > Cc: [email-masked]
> > Subject: Re: [Diffserv] DS boundary router's default behavior
> >
> >
> > No. I don't see any reasonable way to specify a default
> > traffic conditioner.
> >
> > Of course, we do have a clear definition of what the default
> > DSCP means, but
> > I
> > assume you are asking for more than that, and I don't think
> > you will get it
> > as an IETF output.
> >
> >   Brian
> >
> > "Wang, Yang" wrote:
> > >
> > > Hi,
> > >
> > > Has any Draft or RFC defined the DiffServ boundary router's default
> > > behavior? What I mean is that if I buy a vendor's router,
> > put it at the DS
> > > boundary and do nothing, what this router's behavior is in
> > regarding to DS
> > > traffic.
> > >
> > > Thanks,
> > >
> > > Yang Wang
> > >
> > > UUNET
> > > An MCI WorldCom Company
> > >
> > > _______________________________________________
> > > diffserv mailing list
> > > [email-masked]
> > > http://www.ietf.org/mailman/listinfo/diffserv
> > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> >
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> 
> -----
> Message-ID: <[email-masked]>
> From: "Yoram Bernet (Exchange)" <[email-masked]>
> To: Brian E Carpenter <[email-masked]>, "Wang, Yang" <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Diffserv] DS boundary router's default behavior
> Date: Wed, 8 Dec 1999 07:52:13 -0800
> X-Mailer: Internet Mail Service (5.5.2650.21)
> 
> that said - there was a draft filed by myself, david durham and fran
> reichmeyer, about expected behaviour from diffserv boundary routers. the wg
> consensus at the time was that
> 
> 1) it looked too far forward (was too speculative)
> 2) focused too much on the interoperation of diffserv with signaling
> 
> (Brian - pls correct if i have misrepresented)
> 
> so - we were asked to shrink it considerably and ended up with the
> conceptual model draft. ourselves and others are still working on many of
> the features in both drafts.
> 
> the first draft is available by searching under the keyword 'diffedge'.
> 
> the second is listed on the diffserv wg web page.
> 
> y
> 
> > -----Original Message-----
> > From: Brian E Carpenter [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> > Sent: Tuesday, December 07, 1999 8:26 AM
> > To: Wang, Yang
> > Cc: [email-masked]
> > Subject: Re: [Diffserv] DS boundary router's default behavior
> >
> >
> > No. I don't see any reasonable way to specify a default
> > traffic conditioner.
> >
> > Of course, we do have a clear definition of what the default
> > DSCP means, but I
> > assume you are asking for more than that, and I don't think
> > you will get it
> > as an IETF output.
> >
> >   Brian
> >
> > "Wang, Yang" wrote:
> > >
> > > Hi,
> > >
> > > Has any Draft or RFC defined the DiffServ boundary router's default
> > > behavior? What I mean is that if I buy a vendor's router,
> > put it at the DS
> > > boundary and do nothing, what this router's behavior is in
> > regarding to DS
> > > traffic.
> > >
> > > Thanks,
> > >
> > > Yang Wang
> > >
> > > UUNET
> > > An MCI WorldCom Company
> > >
> > > _______________________________________________
> > > diffserv mailing list
> > > [email-masked]
> > > http://www.ietf.org/mailman/listinfo/diffserv
> <http://www.ietf.org/mailman/listinfo/diffserv>
> > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> <http://www-nrg.ee.lbl.gov/diff-serv-arch/>
> >
> >
> >
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/diffserv
> <http://www.ietf.org/mailman/listinfo/diffserv>
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> <http://www-nrg.ee.lbl.gov/diff-serv-arch/>
> >

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 07:29:05 -0800

y

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 10 Dec 1999 09:55:17 -0800

> developing "best practice" than it is standards work.

Hmmm.... right now I'm swayed more by the belief that default ingress
behaviors are indeed a standards issue. After all, we've defined the
default forwarding behavior. We've defined that at some point an
MF-classifier is used to assign DSCPs to packets going past. It
seems reasonable to define the "default" classification process that
leads to assigning the DSCP = 000000.

It could be as simple as a "should" statement. E.g. "A router using
MF classification to assign DSCPs SHOULD explicitly assign the
default DSCP to packets that do not match any pre-configured MF
classifier rules." This would meet the goal of protecting the core
by default - sort of "do no harm to the rest of my network" goal.

(Clearly there's a "do no harm to the original packet" variant,
where a router SHOULD leave the DSCP untouched if the MF classifier
fails to match the packet against any pre-configured rules... but my
sense is operators would prefer the default to be "do no harm to the
rest of my network")

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 10 Dec 1999 12:33:39 -0800

Grenville Armitage wrote:
...
> sense is operators would prefer the default to be "do no harm to the

This sounds reasonable to me. Perhaps such a statement could be included
in future versions of RFC 2474 and RFC 2475? Comments?

	Kathie

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Dec 1999 15:14:28 -0600

Grenville,

While I agree that what you suggest is a very plausible operational
default, the IETF tends to wait for experience before writing down 
operational rules. 

   Brian