The MPLS WG Archive

["Dutta, Pranjal" <pdutta@riverstonenet.com>]

Hi Eric,
           Thanks for the detailed explanation. Kindly refer my
statements inline.

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com] 
Sent: Tuesday, 11 April, 2006 11:20 PM
To: Dutta, Pranjal
Cc: mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of receive
label mapping for prefix FECs 


> In Inter-IGP-area or inter-AS case  the routes from Rd would be
summarized
> to Ru and in such a case Ru MAY not find the exact match for such FEC
x

If I  understand your  example, Ru has  the summary  route, Rd has  the
more
specific routes, and  Rd is sending Ru label bindings  for the more
specific
routes  but not  for the  summary route.  

[Pranjal] Yes, that's exactly the scenario of my problem. <snip>
 

You don't say anything  about Ru
itself  distributing  labels  bindings  for  the more  specific  routes,
so
presumably the only thing  at issue is Ru should label an  IP packet
that it
receives. 

[Pranjal] This is the point that I had raised. If there is no exact
match in route table, but LPM finds a shorter prefix, Ru should be able
to act as ingress LSR for the FEC and should send labeled packets to Rd
if its next hop. But should it make a local binding for the same FEC and
distribute to Ru's upstream LSRs? As per RFC 3036 we should have an
*exact* match else we can't further extend the LSP to upstream. My
question was as that since the FEC has matched a LPM prefix P at Ru, why
can't Ru consider it for local binding and accordingly adverstise to its
upstream LSRs? This condition would arise when Ru and Rd are
inter-IGP-Area Border routers or AS border routers.<snip>

What will happen is that the IP packet gets sent unlabeled to Rd
which then labels it according to the specific route which is the best
match
to the packet's IP destination address.

[Pranjal] That means if *exact* match is not found at Ru for the FEC
binding from Rd, the label won't be used at all and packets will go to
Rd as unlabelled as per RFC 3036.<snip>

The label imposition procedure here is: 

- get the IP destination address
- find  the prefix  in the routing  table which  is the best  match
(longest
  match) for that destination address
- use the label  which was assigned to that prefix by  the LSR which
routing
  says is the next hop for that prefix. 

It  doesn't make sense  for Rd  to bind  labels to  prefixes which  are
more
specific  than  the  one in  the  routing  table,  as the  label
imposition
procedure will never make use of such labels. 

I don't think we want to allow  LDP to put prefixes in the routing
table, or
else we'd  have to  treat it as  a second  routing algorithm and  that
would
raise all kinds of issues.

[Pranjal] So, the reason for *exact* match imposition that I could
understand is that we don't want routes/prefixes to be added by LDP into
FIB. It's the job of routing to manipulate FIBs and here only thing LDP
needs to do is to identify entries in FIB to be labeled for downstream
LSRs and for local binding accordingly <snip>

It is possible though to imagine a different imposition procedure: 

- get the IP destination address, A

- find the prefix, P, in the routing table which is the best match
(longest
  match) for that destination address

- get the next hop, N, for P, as specified by routing

- if N has distributed any label bindings for prefixes which are longer
than
  P but begin with the same sequence of  bits as P, and if any of these,
say
  Q, is a better match for A than  P, then use the label which N
assigned to
  Q. 

This is a complicated procedure, though.   You can't just match A
against Q,
because there might be some prefix  R in the routing table, with a
different
next hop, which is  a better match for A than P is, but  not as good a
match
as Q.  The above imposition procedure  says that the next hop for the
packet
is determined  by the  route to  R not  by the route  to P  (or Q).
It's a
complex matter  to keep  the forwarding tables  in proper shape,  given
that
prefixes like Q can come and go asynchronously. 

There are other  complications as well.  For example, what do  you do if
you
get a packet  which is labeled for Q,  but the next hop has  changed and
the
new next hop has not distributed a label for Q?  

[Pranjal] These are the exact issues that I am facing when I consider
the FECs based on LPM (against RFC 3036). The problem comes is syncing
up the LIB with routing table changes. Especially, the problem is
handling an event
like "next hop change". In that *exact* match case its easier, we need
to see if the entry's next hop has changed. In case of LPM, if the
prefix P
Itself might have changed/broken up into longer prefixes and that would
require LPM match again and complications arise in syncing up ("who is
my new prefix P' and its next hop").<snip>

I suppose we could figure all this out if there were an actual problem
which
didn't have a better solution. 

[Pranjal] Thanks for the detailed case wise explanation. The only thing
I see now is that we can't have inter-AS, inter-area LSPs now as routes
will
be summarized across domains.

Regards,
Pranjal <snip>




   

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls