[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Diffserv] DS boundary router's default behavior

To: diffserv@xxxxxxxx
Subject: RE: [Diffserv] DS boundary router's default behavior
From: "Wang, Yang" <ywang@xxxxxx>
Date: Fri, 10 Dec 1999 17:03:35 -0500
List-id: <diffserv.ietf.org>
Sender: diffserv-admin@xxxxxxxx
Brian,

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

I don't think that is the case since current routers don't automatically
reset the bits and the network doesn't need to care about it since it only
provides the "best effort" service.

Yang


"Wang, Yang" wrote:
> 
> 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:swb@newbridge.com]
> Sent: Friday, December 10, 1999 11:16 AM
> To: Wang, Yang
> Cc: diffserv@ietf.org
> 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:ywang@uu.net]
> >Sent: Tuesday, December 07, 1999 2:49 PM
> >To: 'Brian E Carpenter'; Wang, Yang
> >Cc: diffserv@ietf.org
> >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:brian@hursley.ibm.com]
> >Sent: Tuesday, December 07, 1999 11:26 AM
> >To: Wang, Yang
> >Cc: diffserv@ietf.org
> >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
> > > diffserv@ietf.org
> > > http://www.ietf.org/mailman/listinfo/diffserv
> > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> >
> >_______________________________________________
> >diffserv mailing list
> >diffserv@ietf.org
> >http://www.ietf.org/mailman/listinfo/diffserv
> >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> >_______________________________________________
> >diffserv mailing list
> >diffserv@ietf.org
> >http://www.ietf.org/mailman/listinfo/diffserv
> >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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: brian@icair.org
Ethernet address: 00-00-AC-CF-5B-82

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

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
Prev by Date: Re: [Diffserv] DS boundary router's default behavior
Next by Date: [Diffserv] Committed Access Rate
Previous by thread: Re: [Diffserv] DS boundary router's default behavior
Next by thread: RE: [Diffserv] DS boundary router's default behavior
Index(es):
- Date
- Thread