The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [Diffserv] RE: MPLS Diffserv Extensions related questions/com ments
Puneet, This draft explains MPLS operation over Diffserv. The change of DSCPs of unlabeled IP packets, which are due to crossing boundaries, is something which is done before this stage, with or without MPLS. That is why Section 2.1.2 says: " For packets received unlabelled, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and uses the DS field." So whatever is done in non-MPLS IP Diffserv router is done also here, which includes the DSCP conversion. I don't really think we need to write all this operation here. Regards, -Shahram >-----Original Message----- >From: Puneet Agarwal [mailto:puneet@pluris.com] >Sent: Thursday, June 01, 2000 11:05 PM >To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET >Cc: diffserv@ietf.org >Subject: RE: [Diffserv] RE: MPLS Diffserv Extensions related >questions/com ments > > > >For the "IP to MPLS label push" case, section 2.1.2 of the -04 >draft says >that we use the DS field as the Incoming PHB. However, if the >incoming IPv4 >packet's DS field is invalid (as the router is the ingress edge of a >diffserv domain), the packet needs to be first classified to >determine the >DSCP for the packet. I think that it is this DSCP that should >be used to >determine the Incoming PHB in the case outlined. The draft was not very >explicit in this regard. > >Moreover, is it required that this newly computed DSCP be >placed in the IP >packet's DS field before pushing the outgoing label(s)? > >-Puneet > >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Thursday, June 01, 2000 3:12 PM >To: 'Bora Akyol'; Shahram Davari; mpls@UU.NET >Cc: diffserv@ietf.org >Subject: [Diffserv] RE: MPLS Diffserv Extensions related >questions/comments > > >Hi Bora, > >Sorry my fault. I was answering your question from the Version >-05 of the >draft, which will be released very soon. In any case I >presented the Pipe >and Uniform model in Adelaide and we are currently finishing the final >details of this version. > >With this in mind, please see my comments: > >>-----Original Message----- >>From: Bora Akyol [mailto:akyol@pluris.com] >>Sent: Thursday, June 01, 2000 4:42 PM >>To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET >>Cc: diffserv@ietf.org >>Subject: RE: MPLS Diffserv Extensions related questions/comments >> >> >> >>See Comments within: >> >>By the way, I have version 04 of this draft from IETF web site, which >>version do you have? >> >>Thanks >> >>Bora >> >> >>> -----Original Message----- >>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> Sent: Thursday, June 01, 2000 10:20 AM >>> To: 'Bora Akyol'; mpls@UU.NET >>> Cc: diffserv@ietf.org >>> Subject: RE: MPLS Diffserv Extensions related questions/comments >>> >>> >>> Hi Bora, >>> >>> Please see my comments below: >>> >>> >-----Original Message----- >>> >From: Bora Akyol [mailto:akyol@pluris.com] >>> >Sent: Thursday, June 01, 2000 12:28 AM >>> >To: mpls@UU.NET >>> >Cc: diffserv@ietf.org >>> >Subject: MPLS Diffserv Extensions related questions/comments >>> > >>> > >>> >I have a few questions on the 4th revision of this draft. >>> >(Possibly with >>> >more to follow) >>> > >>> >1. Does this draft assume that an E-LSP is associated with >>> >only one prefix? >>> >At least in our implementation, we can direct more than one >>> >prefix into a >>> >single LSP. >>> >>> No. An E-LSP is associated with one FEC. That FEC may include >>> one or more >>> prefixes (see section 3.1). >> >>I have read section 3.1 and it does not define what an FEC is. >>Which leads >>me to believe that the FEC definition is the one that is used >>in LDP which >>essentially is a prefix. >> > >This document is not the place to define FEC or other >previously defined >terms. FEC is defined in Architecture and framework documents. >They both >mention that although FEC is commonly associated with an >address prefix, >this is not a requirement. In fact using CR-LDP FEC element you could >arbitrarily assign anything you want to an FEC. > >>> >>> > >>> >2. What happens when penultimate hop popping is used for an >>> E-LSP? The >>> >penultimate hop really does not have knowledge about the EXP >>> >mappings in the >>> >ultimate hop? >>> >>> Let me extend your question to the two cases in the draft, >>> (i.e.,Pipe and >>> Uniform tunnels): >> >>I am sorry in the version that I have there is no discussion >>of "pipe" or >>"uniform" tunnels. I have -04 version, is there a newer >>version available. >> >> >>> >>> 1) Pipe: in this model there is no need for the penultimate >>> hop to convey >>> the top label's diffserv information (i.e., before popping) >>> to the ultimate >>> hop. What happens is that the top label's diffserv >>> information is used by >>> the penultimate hop only for the diffserv scheduling and >>> queuing treatment >>> in that node, while the packet is sent to the ultimate hop, without >>> modifying the lower label (the label after pop). Therefore >>> there is no need >>> for the penultimate hop to know anything about EXP <=>PHB >>> mapping of the >>> lower label entry. >>> >> >>Yes, but what happens if the penultimate hop pop exposes an IP >>packet, then >>what do I put in the DSCP field of the IP packet? >> > >This is basically the same problem, which limits the use of >PHP in Uniform >model. Some possible solutions: > >1) Don't use PHP with uniform model >2) Configure the PHP router to know the EXP<=>PHB and/or >DSCP<=>PHB mapping > > > >>> 1) Uniform: In this case the penultimate hop must convey the >>> top label's >>> diffserv information to the ultimate node by encoding the >>> lower label entry. >>> Therefore the penultimate hop SHOULD know (either by >>> configuration or other >>> means) about the EXP <=>PHB mapping of the lower label and/or >>> the LSP type >>> (E-LSP or L-LSP), otherwise PHP can't be used. In fact this >>> applies to both >>> E-LSPs and L-LSPs in the Uniform model with PHP. So you are >>> correct in this >>> case, and if my co-authors have no objection , we could add >>> this restriction >>> to the draft. >>> >> >>Yes, thank you. >> >>> >>> > >>> >3. How does one tie the output of the policing element in the >>> >model to the >>> >EXP bits on the output direction of the label. Even though the >>> >picture in >>> >the draft shows this connection, the text does not cover this. >>> > >>> >>> It is explained in section 3.5 and 4.5 "Encoding Diffserv >>> information in to >>> encapsulation layer on outgoing E-LSP and L-LSP". Basically >>> after policing a >>> packet belonging to a PHB you derive a new PHB and then you >>> can encode this >>> new PHB in to the EXP field using procedures explained in >>> these sections. >>> >> >>Copied from draft verbatim: >> >>--------------- >> >>3.5 Encoding Diff-Serv information into Encapsulation Layer >On Outgoing >>E-LSP >> >> This section defines the mandatory default method for encoding of >> Diff-Serv related information into the MPLS encapsulation Layer to >> be used when a packet is transmitted onto an E-LSP. This method >> requires that the `Set of PHB-->Encaps mappings' is populated as >> defined above in section 3.4. >> >> The LSR first determines the `Set of PHB-->Encaps Mapping' >> associated with the outer label of the NHLFE. >> >>3.5.1 `PHB-->EXP mapping' >> >> For all the labels which are swapped or pushed, the LSR: >> - determines the PHB-->EXP mapping by looking up the >> `Set of PHB-->Encaps mapping' of the Diff-Serv context >> associated with the corresponding label in the NHLFE. >> - determines the value to be written in the EXP field of the >> corresponding level label entry by looking up the >"outgoing PHB" >> in this PHB-->EXP mapping table. >> >>3.5.2 `PHB-->802.1 mapping' >> >> Le Faucheur et. al 13 >> >> >> MPLS Support of Diff-Serv March 00 >> >> >> If the `Set of PHB-->Encaps mapping' of the outer label contains a >> mapping of the form `PHB-->802.1 mapping', then the LSR: >> - determines the value to be written in the >User_Priority field of >> the Tag Control Information of the 802.1 encapsulation header >> [IEEE_802.1], by looking up the "outgoing PHB" in this >PHB-->802.1 >> mapping table. >>-------- >> >>Can you please show me where in the text above it is stated >>how to tie in >>the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping? >> > >Section 2.3 explains that Policer (traffic conditioner) or any >Local policy >may be used to determine the outgoing PHB from the incoming >PHB. This is >shown as block "B" in the first diagram. Then the outgoing PHB >is encoded in >the packet using one of the procedures described above in >section 3.5 or >4.5. > >I hope that helps. We have done some additions and corrections which >probably will better answer your questions. We are trying to >release the new >version ASAP. > >Regards, > >-Shahram > >> >> >>> >4. Why does the draft have so many forward references >>> >especially in Chapter >>> >2. It would have been much better to first complete the >>> >discussion on E-LSPs >>> >fully, then focus on L-LSPs. This makes the text difficult >>to follow. >>> >>> The reason is that section 2 applies to both E-LSPs and >>> L-LSPs and if we >>> want to first completely describe E-LSPs then L-LSPs, we need >>> to repeat a >>> lot of text. >>> >> >>Unfortunately, makes it hard to follow. >>> > >>> >5. The draft is vague on the following cases: >>> > a) IP to MPLS label push >>> > b) MPLS to IP label pop and route >>> > c) MPLS to IP pop, then IP to MPLS push. >>> >> >>Oops, my version does not have these sections. >> >> >>> These operations are fully explained in section 2.6.3 and >>> 2.6.4 for Uniform >>> and Pipe model. In our model we have tried to break down the >>> push, pop and >>> other operations individually without describing all the possible >>> combinations, this makes the text much shorter and any >>> possible combination >>> can be figured out by replacing the individual operation in the flow >>> diagram. If there is anything specific that you think we have >>> not covered >>> please specify in more details, so that we can add it to the draft. >>> >>> > >>> >6. For the people that are actually using MPLS with Diffserv >>> >rather than >>> >just the CoS bits, how are you using it? >>> > >>> >7. Is the terminology in the draft going to get updated to >>> >sync up with the >>> >latest and greatest diffserv terminology ( I have to admit >>> >that I tuned out >>> >that discussion about 3 weeks ago). >>> >>> The terminology is already updated. If you have any specific >>> doubt please >>> let us know. >>> >>> > >>> >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, >>> >etc while this >>> >spec was being written? This actually is one of my biggest >>> gripes about >>> >Diffserv. It is so damn flexible which makes almost any HW >>> >implementation >>> >leave out features, maybe we should have started something >>> >that was concrete >>> >and implementable. >>> > >>> >One suggestion, it may not be a bad idea at all to move at >>> >least one of the >>> >examples to the front of the text to set some context. >>> > >>> >>> Thanks for your suggestions. >>> >>> Regards, >>> Shahram >>> >>> >>> >Thanks >>> > >>> >Bora Akyol >>> > >>> >> > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > |
|