The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

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.

> 
> >
> >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?

> 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?

 

> >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
> >
>