Subject: RE: Arch Draft 06, PHP & LSP

From: Joel Halpern <[email-masked]>
Date: Mon, 13 Sep 1999 15:03:40 -0400

I have to agree with Paul and Eric Gray that there is something that
needs addressed here.  It may be "where is the end-point", or it may be
"who is participating".

The example that I would use is a ISP based VPN using MPLS tunnels.
Between two customer facing routers there may be multiple MPLS tunnels.
Each one would use a single label, and correspond to a single VPN (for
some definition of VPN).  When the end router receives the labeled
packet, it decides which customer to deliver the packet to based upon
the label it received.

Does this really mean that the LSP extends to the customer router?
If we want to say yes, we MUST aqdd text that is very explicit about
this interpretation, because many people will miss it.
If we want to say no, we MUST be equally clear, since some of the group
participants already thought the text meant otherwise.

While I have a preference (not the LSP does not extend), I believe that
the current text, while it implies that the LSP does extend, is not
particularly clear on the matter.  And unfortunately this will probably
turn out to affect implementations in subtle ways.

Yours,
Joel M. Halpern

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Monday, September 13, 1999 2:39 PM
To: [email-masked]
Cc: PAUL NADJ; Navin kumar Agrawal; MPLS WG MailingList
Subject: Re: Arch Draft 06, PHP & LSP

Eric,

	Oh, dear - whatever am I to do?  It seems as if
I have to disagree with you again :-)

	The definition you give is just not as simple as
you make it out to be.  Sorry about that.

	The 'complexity' not addressed in this definition
was the point of the discussion (I mentioned earlier) in
LDP (between Bob Thomas, Yoshihiro Ohba and myself) - it
makes a difference whether R[i] and R[i+1] are in the
same MPLS domain (or whether or not R[i+1] is in any MPLS
domain at all when it comes to control plane operations.
Definitions that define an LSR as part of an LSP for data
plane operations and not for control plane operations are
'weird'.

You wrote:
> 
> Paul> The idea is to convey  some useful information about the packet
(i.e.,
> Paul> the   FEC)  to   the  downstream   router.   (The   information
being
> Paul> 'interpretable' only by the downstream router, of course).
> 
> No, this is not the idea.
> 
> Paul> Since labels are downstream assigned, the  idea is not only to
get the
> Paul> packet  to the downstream  router --  one label  per interface
or one
> Paul> label per router would suffice for that.
> 
> If all LSRs  know, for each packet, the identity of  the egress
router, then
> there is nothing to stop them from  using one label for all packets
with the
> same egress router.  See the section on egress-targeted label
assignment.
> 
> Paul> My beef is the definition of an LSP which says:
> 
> Paul> - The LSP includes routers R1 .. Rn (stated)
> Paul> - R[n-1] is the last router to use the label to forward (very
strongly
> Paul>   implied).
> 
> Paul> If  PHP is  not  used,  Rn may  use  the label  to  make a
forwarding
> Paul> decision.
> 
> No it may  not.  More precisely, if  Rn uses the label to  make a
forwarding
> decision,  then  Rn is  not  the  egress router,  and  the  LSP
includes  an
> additional router after Rn.
> 
> Paul> Therefore  if Rn  is using  the  level m  label as  per Eric
[Gray]'s
> Paul> comments, the LSP really ends on R[n+1].
> 
> Correct.
> 
> Paul> Kind of weird to say the  LSP terminates on an R totally
uninvolved in
> Paul> the setup of the LSP, dontcha think?
> 
> So your beef  is that the definitions seem "kind  of weird"?  The
definition
> has to do with  the forwarding plane not the control plane,  so the
issue of
> "setup" isn't really relevant.
> 
> Look at it this way.  With the existing definition, R[i] and R[i+1]
are in a
> particular packet's level m  LSP if and only if R[i] uses  the level m
label
> as the  basis for  forwarding the  packet to R[i+1].   That doesn't
seem so
> weird, though of course it is not the only possible way the terms
could have
> been  defined.  Of  course,  however one  defines  the terms,  it is
always
> possible to define them differently.