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

From: Martin Picard <[email-masked]>
Date: Wed, 06 Dec 2000 07:21:55 -0500

What do you mean by Terminating LSR ?
If you mean egress-LER, then you should not receive "labelled" packets
at all for these destinations since the upstream LSR which is the
penultimate hop should pop the label.
If you have more than one label on the stack, as the stack depth decreases
processing is the same on the top label and eventually the penultimate hop
will output an unlabelled packet to the egress-LER.
What do you mean by no LSP available in the domain ?
Do you mean that for a particular LSR the label space is exausted and
no free labels exist ?

mp

> Thats fine and thanks for your reply.
> But, What I mean is what will be the LSR process if the processing LSR is
> the Terminating LSR and after that there is no LSP available in the
domain.
>
> Cheers,
> mani
>
> -----Original Message-----
> From: Martin Picard [mailto:[email-masked]]
> Sent: Wednesday, December 06, 2000 5:17 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: (Reply) RE: (Reply)
>
>
> Seenu, Manik,
>
>   "the only safe procedure is to discard the packet" -
> draft-ietf-mpls-arch-07 section 3.22
>
> martin
>
>
> > Hi manik,
> >
> > I would like to clarify my previous mail.
> >
> > If a packet comes and if it contains Invalid Incoming Label (there is no
> Label Entry with the "In Label" in the label switching matrix)
> > then it should be dropped.
> >
> > If a packet comes and  it has valid Incoming Label Entry, but no Out
going
> label....This is the egress case...So, need to apply conventional routing
> > on the packet.
> >
> > Regards,
> > Seenu
> > Samsung India Software Operations
> > Level 7, Prestige Meridian - II
> > M.G.Road, Bangalore, India.
> >
> > Tel: +91-80-558 1281 ext: 268
> >
> > =============================
> >
> > Hi manik,
> >
> > You need to drop the packet.
> >
> > For more infromation pls go thorugh  the section
> > "3.18. Invalid Incoming Labels" in  "draft-ietf-mpls-arch-07.txt"
> >
> > Regards,
> > Seenu
> > Samsung India Software Operations
> > Level 7, Prestige Meridian - II
> > M.G.Road, Bangalore, India.
> >
> > Tel: +91-80-558 1281 ext: 268
> >
> > =============================
> >
> > Hi all,
> >
> > I am working on MPLS protocol implementation.
> >
> > I have a doubt on MPLS forwarding process. If I received the labeled
> packet
> > which does not have the entry Label Information Table (I mean does not
> have
> > the outgoing label entry).. What I have to DO?
> >
> > 1. Do I have to drop the packet
> > 2. Do I have to strip of the Shim header and go for conventional IP
> routing.
> >
> >
> > Thanks in advance,
> > Manikandan.V
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

---

From: Martin Picard <[email-masked]>
Date: Wed, 06 Dec 2000 08:31:39 -0500

Dan,

The LER does not get a labelled packet. It gets an IP packet.
The LSR facing the LER (called upstream LSR for that LSP),
will get the labelled packet and will map the incoming label
to an outgoing label of "Pop Label" which means that the
next hop is the ultimate destination and in order to avoid
double lookups in the LER (one for the Label and one for IP)
it just strips off the label and send the packet unlabelled to
the LER which will "route" the packet.

Hope I am not making this worst than it really is.
You can always look at mpls-arch draft section 3.16
to get it from the horse's mouth !

mp

> up until you explained it, i thought i understood it.
>
> so the label edge router gets a labeled packet.  it has no path to send it
> out on.  the indicator in the label says it is the last label.  now it
pops
> off the label and routes the packet.
>
> what am i leaving out?
>
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Martin
> Picard
> Sent: Wednesday, December 06, 2000 7:22 AM
> To: Manikandan.V
> Cc: [email-masked]
> Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply)
>
>

---

From: Martin Picard <[email-masked]>
Date: Wed, 06 Dec 2000 10:19:24 -0500

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 

  -----Original Message----- 
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Martin 
  Picard 
  Sent: Wednesday, December 06, 2000 8:32 AM 
  To: dan martin 
  Cc: [email-masked] 
  Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply) 

  Dan, 

  mp 

  pops

---

From: [email-masked]
Date: Tue, 19 Dec 2000 07:22:59 -0000

Serge...I agree with your comments.  Ultimate hop popping is required to get
the correct functional arch behaviour of the LSP trail termination point.
Practical examples of this would be:
-	to have correct server->client adaptation in normal operation
-	to have correct defect handling from OAM processing, and again take
the correct server->client consequent adaptation mapping actions
-	to have a clear end point for perf monitoring
-	to have a clear end point for prot-sw functionality (based on say
defect detection at that point).

neil

> From:	Serge Maskalik [SMTP:[email-masked]]
> Sent:	Tuesday, December 12, 2000 11:51 PM
> To:	Martin Picard
> Cc:	[email-masked]; [email-masked]; [email-masked]
>    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
> > >
> > >
> > >
> --------------------------------------------------------------------------
> --
> > ----
> > 
> > 
> > 
> > À : 'Martin Picard'
> -- 
>  ---------------------
> |Serge Maskalik       |
> |Sr. Network Architect|
> |iVMG, Inc.           |
> |408.468.0480 office  |
> |408.507.7374 mobile  |
>  ---------------------