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

From: "Wang, Yang" <[email-masked]>
Date: Fri, 10 Dec 1999 13:44:01 -0500

I would like to see this issue and this kind of statement go in some docs.
If this is an only or best solution to this issue, then the following
questions come out. 1. To a current network, all existing edge routers need
to migrate to the new feature (resetting DS field) to secure the core in
order to deploy the DiffServ. For a large network, is this doable in a
reasonable time? 2. What is the edge router performance since it requires
edge routers to reset DS field for the incoming traffic at all INTERFACES
(interfaces and sub-interfaces)? I think the questions touch to the
fundamental DiffServ architecture issue and would like to get some answers.

Thanks,

Yang

-----Original Message-----
From: Scott W Brim [mailto:[email-masked]]
Sent: Friday, December 10, 1999 11:16 AM
To: Wang, Yang
Cc: [email-masked]
Subject: RE: [Diffserv] DS boundary router's default behavior

You're suggesting that edge equipment should come with safeguards to 
protect resources in the core, for example a default of clearing all 
diffserv markings unless told to do otherwise.  Agreed, but this isn't a 
protocol issue, and it's not required for interworking of different 
vendors' equipment.  A statement like that could (should) go in an 
analysis document or a BCP, when we start producing them.

...Scott

At 09:40 12/10/1999 -0500, Wang, Yang 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".
>
>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.
>
>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/

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

---

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

Yang,

Diffserv is believed to scale exactly because traffic conditioning is applied
in a fully distributed way, at every interface on every edge box. There is
nothing special about a default conditioner in this respect; it's
only 'else DSCP=0' stuck at the end of all the rest of the conditioners.

I suspect that many ISPs already protect themselves by zero'ing the TOS byte
anyway.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]
Ethernet address: 00-00-AC-CF-5B-82