The MPLS WG Archive[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 ...
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 _________________________________________________________________ |
|