The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Feb> msg00061



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

<draft-ietf-mpls-diff-ext-08.txt> on its way ...

  • From: Francois Le Faucheur <flefauch@cisco.com>
  • Date: Fri, 09 Feb 2001 18:04:37 +0100
  • Cc: diffserv@ietf.org, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, daha@ironbridgenetworks.com, murphy@juniper.net, curtis@avici.com, aatlas@avici.com, Vijay.Srinivasan@cosinecom.com, swallow@cisco.com, xiaoxipe@cse.msu.edu, telkamp@GBLX.net, Pierre.Merckx@sita.int, martin.tatham@bt.com

Hello,

Subsequent to the MPLS WG Last Call, a special Diff-Serv WG Last Call was
issued on <draft-ietf-mpls-diff-ext-07.txt> at the request of the Area
Directors.

We received comments relating to two items. Below are the details of the
planned resolution for both items.
We will shortly post version 08.txt incorporating these resolutions. 

Cheers

Francois


L-LSPs EXP<-->PHB mapping
=========================
We plan to incorporate Jim Murphy's suggestion to modify the EXP value
corresponding to AFn3 L-LSPs. AFn3 would be mapped to EXP=011 (instead of
010).
For memory, the rationale is that implementations which support only two
drop priorities per AF class could determine the drop priority to be
applied by looking at a single bit. Same idea was used for the DSCP
encodings for AF.

The EXP value will be changed accordingly in sections 4.2.1 (in the
example), 4.2.1.1 (in the mapping table), 4.4.1 (in the example), 4.4.1.1
(in the mapping table).


Incoming PHB Determination with Pipe Model
===========================================
We received pretty much the same comment from several people (Service
Providers as well as vendors) on one detailed aspect of the Pipe model:
output scheduling at egress of a Pipe LSP. 
"xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming
PHB determination based on the "inner header" (ie after the POP). We plan to:
	- keep such a behavior, but make it an optional variation of the Pipe model
	- define an alternative behavior where the egress LSR does incoming PHB
determination based on the "outer header" (ie before the POP). This will be
the normal egress behavior for the Pipe Model.
All the other aspects of the Pipe model are unchanged.

The rationale for using "outer header" by default on egress of Pipe is the
following:
	- the typical application of the Pipe model is where a Service Provider
(SP) transports traffic from a customer who uses a different Diff-Serv
policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based
on the outer header (and assuming no PHP) allows the Service Provider to
configure scheduling based on its own Diff-Serv policy. Doing scheduling
based on the inner header forces the Service Provider to be aware of each
and every customer Diff-Serv policy and forces the SP to configure
scheduling differently for each customer Diff-Serv policy. The most common
situation will be that the SP does not want to be even aware of the
Customer Diff-Serv policy and thus need to use the outer header. 
(There will be cases where the SP may accept the operational overhead of
being aware of the customer's Diff-Serv policy and sell "egress scheduling
based on customer's policy" as a value add; this is why we keep the use of
inner header as an option. But this will be less common.)
	- again, use of inner header means that scheduling is based on customer
Diff-SErv policy, which can be different for each egress port. For router
platforms using some form of input queueing, this translates in additional
sophistication since the input queueing must then be made aware of the
Diff-Serv policy of every customer connected to an egress port (unless
input queueing is performed on outer header even if egress scheduling is
based on inner header, but that means performing classification twice: once
on input and once on output). While this is implementable, it is
undesirable to mandate such sophistication/cost as part of the mandatory
Pipe mode.
	- use of outer header and use of inner header are both allowed in RFC2983
(from which the Uniform and Pipe models are inherited).

This will result in corresponding text changes in section 2.6.2. 




>Message-ID: <3A1BE887.CB342532@hursley.ibm.com>
>From: Brian E Carpenter <brian@hursley.ibm.com>
>To: Diff Serv <diffserv@ietf.org>
>Cc: George Swallow <swallow@cisco.com>, Vijay Srinivasan
>	<vijay@cosinecom.com>, Scott Bradner <sob@harvard.edu>, Allison Mankin
>	<mankin@isi.edu>, Rob Coltun <rcoltun@redback.com>, Kathleen Nichols
>	<nichols@packetdesign.com>
>Subject: [Diffserv] Special last call for draft-ietf-mpls-diff-ext-07.txt
>Date: Wed, 22 Nov 2000 07:38:48 -0800
>MIME-Version: 1.0
>X-Mailer: Internet Mail Service (5.5.2650.21)
>Content-Type: text/plain
>
>Diffservers,
>
>draft-ietf-mpls-diff-ext-07.txt has passed Last Call in the MPLS working
group,
>but since it concerns Diffserv, this is a special last call at the request
>of the Area Directors.
>
>If you have any issues and concerns with the document that have not
>previously been raised on the MPLS list, please raise them before
>December 6. 
>
>Also, please direct your comments to the MPLS mailing list, not
>the diffserv list, since it is their document, not ours!
>
>The MPLS list is at mpls@uu.net
>
>The draft is at
http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-07.txt
>
>Regards
>   Brian + Kathie
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 



_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________