-----Original Message-----
...[SNIP]...
<>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
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls