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

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

Eric,

> From: Eric W Gray [mailto:[e-mail]]

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

[Bruno D:] That is correct if Ru and Rd are in the same IGP area.
Otherwise, if IP aggregation is performed between areas, Ru and Rd may
not have the same IP route knowledge. In particular, if Rd is an Area
Border Router, it may aggregate IP reachability information send to Ru.
Therefore, Rd will not advertise the specific IP route to Ru. You may
also have a look at section 4.1 of
draft-decraene-mpls-ldp-interarea-01.txt for more details on this use
case.


>  LSR-1 would only receive
> label mappings -
> from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at
least).
> 
> 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.
> 
> --
> 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:[e-mail]]
> >> Sent: Tuesday, 11 April, 2006 7:53 PM
> >> To: Dutta, Pranjal
> >> Cc: [e-mail]
> >> 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mpls
> >
> >
> >
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls

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