The MPLS WG Archive

["David Allan" <dallan@nortel.com>]

Hi Eric:

Agree that it is not a situation that should ever arise in a persistent fashion....

Looked at this a few years ago and concluded that with independent mode label distribution, you could get scenarios where there were mismatches in how specific a FEC was vs. what was in the routing LSAs, but that would be a race condition and hooking any mismatches together would be a bad idea....e.g. FECs had to be exact match in order to hook FTN/ILM to NHLFE, and you needed specific routing information to install NHLFE in the first place...

So I agree that implementation wise, if there is a mismatch, then waiting is the ideal response, the condition would go away...

cheers
Dave

> -----Original Message-----
> From: Eric W Gray [mailto:ewgray2k@netscape.net] 
> Sent: Wednesday, April 12, 2006 12:48 PM
> To: Joel M. Halpern
> Cc: mpls@ietf.org
> Subject: Re: [mpls] One LDP Implementation specific question 
> of receive labelmapping 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).
> 
> 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: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
> 
> 

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