Subject: Re: Lack of outgoing label was Re: (Reply)

From: Serge Maskalik <[email-masked]>
Date: Tue, 12 Dec 2000 16:54:46 -0800

Thus spake Martin Picard ([email-masked]):

> Serge,
> 
>    I can see why one would want to carry the semantic of the
>    EXP field all the way to the egress LER but it doesn't mean
>    that it has to be carried via the EXP bits of the MPLS header.
>    In fact, at some point or another, these bits will be mapped to
>    the IP-ToS bits (precedence), so this could very well be done
>    on the penultimate hop.

Sure, one large implementation does first three DSCP re-write to 
the EXP field. This is applicable if EXP-inferred LSPs are discussed.
I think it makes sense to include such knob for the support of label-
inferred LSPs where the the PHB is derrived from the label field 
itself (plus EXP potentially). Agreed? 

> 
>    Although it sounds nice to have a control knob for this, the
>    question would be "Is there a definite need for this ?"
>    "Why would you want to disable optimization ?"

Some of this was addressed above. Also, from operational standpoint,
it is useful to have a similar filtering policy used for classifying
traffic on all LSRs, regardless whether they are ingress, egress or 
mid-point LSRs. Notice, the operator is forced to filter contents in
a complete different field with the PHP approach. In another regard, 
the operator may have to do this anyway do maintain the scope of the
DS domain. 

	- Serge 

> 
> mp
> 
> 
> 
> >  IMO, the network operator should have a choice whether the
> >  explicit or implicit null values are signalled. One may want
> >  to do ultimate hop popping instead of PHP to preserve the
> >  contents of the EXP field at the egress LSR. This is also
> >  applicable to single hop LSPs, in case of which, traffic
> >  would not be encapsulated if implicit null value is signalled.
> >  Most implementations today do not support such control knob.
> >
> >- Serge
> >
> >Thus spake Martin Picard ([email-masked]):
> >
> >> Keith,
> >>
> >> Wether or not the LSR are capable of popping the stack should
> >> be determined at session initialization according to mpls-arch.
> >> But, this is assumed to be the case when peer LSRs are not
> >> ATM or F/R LSRs (lsp-spec section 6).
> >>
> >> Now, when an LSRs knows that its peer is capable of popping the
> >> stack, it should distribute an Implicit Null label for its ultimate
> >> destination prefixes  (mpls-arch section 4.1.5).
> >>
> >> Then, the upstream LSR has no choice but to do penultimate hop
> >> pop since it's been requested with Implicit Null. (mpls-arch section
> 3.16)
> >>
> >> Although designed to be optional and flexible eventually, it looks
> >> like for now, with LSRs not ATM or F/R, the penultimate hop pop
> >> behavior is optionnal but "ASSUMED" for now.
> >>
> >> mp
> >>
> >> >
> >> >
> >> >
> >> > According to section 3.16 of MPLS arch,
> >> >
> >> > "An LSR which is capable of popping the label stack at all MUST do
> >> >  penultimate hop popping when so requested by its downstream label
> >> >  distribution peer."
> >> >
> >> > So I assume that when you say PHP is optional and not mandatory,
> >> > you mean the downstream LSR can optionally choose whether or not
> >> > to request PHP.
> >> >
> >> > However, it appears that the upstream LSR is required to support
> >> > PHP (if it is capable of popping the label stack at all).
> >> >
> >> > Do you agree?
> >> >
> >> > Keith
> >> >
> >> >
> >> >
> >> > > RE: Lack of outgoing label was Re: (Reply)
> >> > > RE: (Reply)Yes, you are right Eyad.
> >> > > Penultimate Hop Pop is an optional behavior.
> >> > > mp
> >> > >
> >> > >   ----- Message d'origine -----
> >> > >   De : Eyad Saheb
> >> > >
> >> >
> >> >
> >>
> >>
> >> -------------------------------------------------------------------------
> ---
> >> ----
> >>
> >>
> >>
> >> À : 'Martin Picard'
> >> >   Envoyé : 6 décembre, 2000 10:14
> >> >   Objet : RE: Lack of outgoing label was Re: (Reply) RE: (Reply)
> >> >
> >> >
> >> >   Last I looked, PHP was not a mandatory req in the MPLS arch.
> >> >
> >> >   Eyad
> >>
> >
> >--
> > ---------------------
> >|Serge Maskalik       |
> >|Sr. Network Architect|
> >|iVMG, Inc.           |
> >|408.468.0480 office  |
> >|408.507.7374 mobile  |
> > ---------------------

-- 
 ---------------------
|Serge Maskalik       |
|Sr. Network Architect|
|iVMG, Inc.           |
|408.468.0480 office  |
|408.507.7374 mobile  |
 ---------------------

----- End forwarded message -----

-- 
 ---------------------
|Serge Maskalik       |
|Sr. Network Architect|
|iVMG, Inc.           |
|408.468.0480 office  |
|408.507.7374 mobile  |
 ---------------------

---

From: Martin Picard <[email-masked]>
Date: Tue, 12 Dec 2000 21:56:52 -0500

Serge,

  If I am mistaken, someone please correct me, but from
  what I can gather out of mpls-diff-ext draft is as follow.

  The use of E-LSPs or L-LSPs only changes the basis on
  which the PHB is determined. As you pointed out in E-LSPs
  the PHB is determined by the EXP bits, but in L-LSPs, the
  PHB is determined by the Label AND the EXP bits.

  That being said, it is still necessary for an LER to map
  between the IP world and the MPLS world.
  For E-LSPs, we can have  EXP<-->IP-Precedence and
  for L-LSPs we can have MPLS-Header<--->IP-DSCP.
  Wether or not this is carried in the EXP bits or "inferred"
  by the label, mapping has to be done. Here again, this has
  to be done, at worst, on the ultimate hop but can also be
  pushed up to the penultimate hop.

  Issues can arise though when the label stack is more than
  one label deep. In that case, when using PHP for L-LSPs,
  the corresponding PHB would be lost at the penultimate hop.
  But then, should the DS domain span multiple levels of
  hierarchy ?

  mp

---

From: Serge Maskalik <[email-masked]>
Date: Tue, 12 Dec 2000 22:23:43 -0800

Comments in-line.

>   pushed up to the penultimate hop.

Conceptually, I agree. However, this functionality should be 
the same throughout the entire MPLS domain. If you are familiar 
with managing a multi-vendor IP/MPLS network, you will agree that 
this behavior is not the same in the two major implementations.
To reach a happy medium, the operator should have this knob. 

>   But then, should the DS domain span multiple levels of

Also should be a configurable feature. One example is MPLS
VPNs (L2 or BGP). Say provider P offers VPN service to customer
C. Customer C connects to provider P in multiple access points
all managed by provider P. Provider P runs MPLS/RSVP TE in the 
core and maintains PE to PE LDP relationship which is tunneled 
through the core LSP mesh. Including the VPN label header, the 
stack is 3 labels deep at this point. Provider P marks packets
on ingress from customer C and pushes the stack. So, a re-write 
must occur to the top-most label in the stack or even every 
label in the stack.

I do not see a problem with re-writes occuring between the 
levels of the LSP hierarchy, in fact, I do not see an 
alternative for the case described above.

	- Serge

---

From: Martin Picard <[email-masked]>
Date: Wed, 13 Dec 2000 09:34:17 -0500

Comments in-line.

====
I am not familiar with multi-vendor MPLS network un/fortunately !!!
But, if the MPLS domain is comprised of multi-vendor equipment,
a consistent mapping has to be performed.
====

- Serge

====
In order to accomplish this, the uniform model has to be used.
But according to mpls-diff-ext, the support of this model is still
optional. The only model that MUST be supported is the PIPE
model, which has separate DS-info at each level of the hierarchy.

mp
====