The MPLS WG Archive
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index][Thread Index][Author Index][Subject Index]
[mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs
-
From: Eric W Gray <ewgray2k@netscape.net>
-
Date: Thu, 13 Apr 2006 09:42:51 -0400
-
Cc: mpls@ietf.org
-
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
-
X-AOL-IP: 24.128.207.21
-
X-Spam-Flag: NO
Title:
Pranjal,
Actually, Rd should not distribute labels for more specific routes
than it has advertised.
This is exactly what is broken in the scenario you describe. What
exactly is the point in
distributing these labels, if the routing paradigm uses summarization
to achieve scalability?
As someone (I think Yakov Rekhter) said many years ago, MPLS is
scalable precisely
because routing is scalable.
--
Eric
Dutta, Pranjal wrote:
Hi,
Please follow inline.
Thanks,
Pranjal
-----Original Message-----
From: Eric W Gray [mailto:ewgray2k@netscape.net]
Sent: Wednesday, 12 April, 2006 10:18 PM
To: Joel M. Halpern
Cc: Dutta, Pranjal; mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of receive
label mapping for prefix FECs
If I understand the problem under discussion correctly, this is the
basic scenario:
LSR-1 (Ru) -----> LSR-2 (Rd)
The initial question was related to how LSR-1 handles a label mapping
received
(presumably in downstream unsolicited label advertisement mode) from
LSR-2,
for a FEC corresponding to an aggregate route (e.g. - 10.1.0.0/16) - if
LSR-1
does not have an exact match route entry.
Assuming that both LSRs are functioning properly and LSR-2 is using LDP
to send
unsolicited label mappings for FECs that correspond to routes it has
advertised, it
is unlikely that this situation will arise. LSR-1 would only receive
label mappings -
from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at
least).
[Pranjal]: The issue I raised is the situation when Rd summarizes the
routes to Ru. So Rd has more specific routes and Ru has summarized
route. This would be the case when Ru and Rd are in different IGP Areas
or AS domains.
In that case, in downstream unsolicited Rd will advertise a label
mapping for those more specific prefixes (FECs). Ru won't find exact
match, but may find a longest prefix match. Now as per RFC 3036 and as
you said we should do exact match for the FEC <snip>
An implementor might decide to incorporate a delay prior to making this
check, in
order to eliminate some potential race conditions. And implementors may
disagree
as to what it means for LSR-1 to have an entry. But - bottom line - if
the check
for an exact match between FEC and route entry finds that such an entry
does not
exist in an LSR, the corresponding label must not be used.
The procedures for handling label mappings are - in part - intended to
provide for
robustness in the event that another LSR is not functioning properly.
Much of the discussion surrounding this question has been about complex
things
an implementation might do. None of these things are fundamentally
incompatible
with the procedures as written.
[Pranjal]: Yes, there are certain things like introducing delay to
handle race condition as you said are implementer's choice. But I have
to follow the basic tenet now, that is the *exact* match for FEC
binding.
--
Eric
Joel M. Halpern wrote:
The basic question is how much complication an implementation wishes
to undertake to allow for the mismatch.
Note that such mismatches are rare.
As a local matter, an implementation can chose to create the FTN entry
for the exact match, and keep track of the relationship between that
entry and the actual routing entry. Eric has argued that such is
undesirable complication. I would tend to agree with him in the
abstract. What you choose to do in your implementation may depend
upon your structures and on what problems you confront in the field.
Creating the local entries and using them is legal. Such entries
would not affect routing advertisements. They probably don't even
effect label advertisements.
Yours,
Joel M. Halpern
At 04:45 PM 4/11/2006, Dutta, Pranjal wrote:
Thanks for the explanation on this.
Let me elaborate a scenario based on the rules that you mentioned.
For the procedure of label_map_received we have to apply both the
rules
1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is
NOT
the next hop for the FEC. How Ru decides that the FEC is not next hop
are
a) FEC exactly matches a route entry but next hop is another LSR or
b)
As per your rule one FEC matches LPM to a shorter prefix P, and Rd is
not next hop for the matched prefix P. Lets say we hit issue b) and
due
to liberal retention at Ru it retains the label but will not be used
for
forwarding.
Now let's say that routing at Ru changes and now Rd becomes next hop
for
Prefix P. So now Ru should introduce an entry for the FEC into
forwarding table and install the NHLFE entry right? But that violates
your Rule 2 then
as the exact match condition should be met. If we apply rule 2 now,
then
we shouldn't use the label from Rd although Rd has become the next
hop
for Prefix P. Please correct me if I am wrong in this.
Regards,
Pranjal
-----Original Message-----
From: Joel M. Halpern [mailto:joel@stevecrocker.com]
Sent: Tuesday, 11 April, 2006 7:53 PM
To: Dutta, Pranjal
Cc: mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of
receive
label mapping for prefix FECs
I think that there may be a better way to explain this. There are
several different factors at work:
1) A received LDP label MUST NOT be used if the neighbor sending the
label is not the next hop for the FEC. This condition does not
require an exact match in the forwarding table.
2) A Received label MUST NOT be used for packets which do not match
the received FEC. This condition requires an exact match in the
forwarding table.
This does allow an implementation to create an exact match entry in
the forwarding table to select packets that use the label, even if
routing provided a shorter prefix. This does allow one to use /32
entries without injecting those /32s into the actual routing
protocol. However, the most common uses of .LDP (even with /32s)
will result in the entries being in the forwarding table anyway.
Another way to look at the condition above is that condition 1 is a
restriction on the use of a received label advertisement. LPM check
is suitable. Condition 2 is a restriction on the contents of the
Forwarding-Table-to-Next-hop-label-forwarding-entry that one
creates. That must be an exact match.
Yours,
Joel M. Halpern
At 07:02 AM 4/11/2006, Eric W Gray wrote:
The implementation MUST do an exact match, as downstream LSRs will
forward based
only on the label. Because they do not (typically) perform a route
look-up on the label
encapsulated inner IP packet, there is no reason to expect a
downstream LSR to be able
to separate a flow based on longest match when the routes further
downstream are distinct
for "longer matches".
Dutta, Pranjal wrote:
Hi Eric,
As per RFC 3036 Label mapping receive procedures, when
Ru
received a label mapping from Rd for a FEC x, Ru need to find an
"exact"
match of the FEC x(IPv4/V6 prefix) in its route table. 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. In
terms
of
RFC 3036 then Ru MAY not find exact match for the FEC received from
Rd
in its route table and no further action at Ru. My question was why
Ru
can't we do a longest prefix match for the FEC x as LPM means it
can
be
reached by a downstream Rd?
Thanks,
Pranjal
_______________________________________________
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
| |
|