RE: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs

["DECRAENE Bruno RD-CORE-ISS" <[e-mail]>]

Eric,

Thanks for your comments.

Additional discussions inlined.

Regards,
Bruno

> -----Original Message-----
> From: Eric Rosen [mailto:[e-mail]]
> Sent: Tuesday, April 11, 2006 7:50 PM
> To: Dutta, Pranjal
> Cc: [e-mail]
> Subject: Re: [mpls] One LDP Implementation specific question of
receive labelmapping 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.   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.  

[Bruno D:] A subsequent issue, is that to continue the LSP further
upstream, Ru should allocate a new label and advertise the specific FEC
upstream to Ruu.

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

[Bruno D:] That is indeed the current behavior but the problem is that
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet BTW.
 
> 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.

[Bruno D:] Such procedure would not change the behavior of the IGP and
LDP.
LDP would definitely not act as a routing protocol and all routing
decisions (next-hop selection, recheability) would still rely on the
IGP. LDP would continue advertising labels for FECs and would entirely
rely on the RIB for setting up LSPs along the IP route.

However, as you very correctly pointed out, we would allow LDP to
"de-aggregate" the FIB and this may raise some issue. However, what is
the difference, from the FIB point of view, between one /30 pointing to
Rd and four /32 pointing to Rd? I believe some FIB implementation
already represent a /30 as four /32.

Besides, if populating the FTN with specific FEC is found to be an
issue, we can only populate the ILM on all P routers. For PE/ingress
router, all we really need is BGP to be aware of these LSPs and be able
to use them to reach the BGP Next Hops.

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

[Bruno D:] I don't think there is a need to change the imposition
procedure at all. The modification of the label mapping procedure seems
enough. However, as pointing out by Dutta, an additional effort is
needed to sync LDP with the RIB because as you said, more specific
prefixes can come and go.

 
> 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?
> 
> I suppose we could figure all this out if there were an actual problem
which
> didn't have a better solution.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls