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

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Thu, 13 Apr 2006 10:27:48 +0200

Eric,

Thanks for your comments.

Additional discussions inlined.

Regards,
Bruno

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 7:50 PM
> To: Dutta, Pranjal
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls

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

---

From: Eric W Gray <[email-masked]>
Date: Thu, 13 Apr 2006 10:03:12 -0400

Bruno,

    No, if anything specific had to be said, it would be that Ru MUST 
NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has 
advertised in routing.

    I cannot speak - obviously - for every implementation out there, but 
here's how I believe
they _should_ work when dealing with an ABR (or other sumarization point):

    o   The ABR-LSR advertises summarized routes into an adjacent Area.
    o   The ABR-LSR distributes labels corresponding to those routes to LDP
          peers adjacent to it in that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in 
those
          cases where it has downstream routing entries corresponding to 
more
          specific routes.
    o   The ABR-LSR MAY - at that point - inject arriving packets on 
downstream
          LSPs - after it performs a routing look-up and discovers an 
FTN (thus
          determing an appropriate label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for scalability 
reasons.  It is not the
intention of MPLS generally to eliminate the need for routing capability 
in the network at
a cost of introducing unscalably large numbers of label distributions 
throughout the same
network.

    Just as an  opinion, a device that is incapable of making this kind 
of routing decision,
has no business being in a position to summarize routes.

--
Eric

DECRAENE Bruno RD-CORE-ISS wrote:

>>...[SNIP]...
>> <>presumably the only thing at issue is Ru should label an IP packet 
>> that it receives.
>
>

---

From: Eric W Gray <[email-masked]>
Date: Thu, 13 Apr 2006 10:16:48 -0400

Bruno/Pranjal,

    One thing I would like to make perfectly clear in this discussion is 
that - if either or
both of you would like to write an ID that proposes changing or 
extending LDP to do
what you suggest, you should do so.  The suggestions you make may be 
well received
by participants in the MPLS working group.

    However, you should not view this as something to "correct" in the 
current LDP
specification.  The point of the current LDP specification work is to 
document what is
being done in current interoperable implementations, now. 

    I believe the point has been sufficiently well made by now that the 
text - as is -
represents current implementation better than the changes you've implied 
or explicitly
suggested should be made with respect to the exact match requirement in 
handling an
arriving label distribution.

--
Eric

---

From: "Raveendra Torvi" <[email-masked]>
Date: Thu, 13 Apr 2006 10:43:32 -0400

Eric,
According to your solution  LSPs are broken at the aggregation boundary or
IGP area boundary, which may not be desirable in case of all-MPLS network.
If main goal is to carry transit traffic by the way of LDP-MPLS switching ,
In case of all-MPLS networks an operator would like to inject only LDP-FECs
in other areas (hence achieve the scalability) or avoid summarization
LDP-FECs at IGP area boundary .. Please help me understand.
Ravi.

On 4/13/06, Eric W Gray <[email-masked]> wrote:
>
> Bruno,
>
>     No, if anything specific had to be said, it would be that Ru MUST NOT
> advertise a more
> specific FEC to an upstream peer (Ruu in this case) than it has advertised
> in routing.
>
>           LSPs - after it performs a routing look-up and discovers an FTN
> (thus
>     Just as an  opinion, a device that is incapable of making this kind of
> routing decision,
>  <>presumably the only thing at issue is Ru should label an IP packet that
> it receives.
>
> [email-masked]://www1.ietf.org/mailman/listinfo/mpls
>
> [email-masked]://www1.ietf.org/mailman/listinfo/mpls
>
>
>
>

--
101 Billerica Ave,
N.Billerica MA -01862

---

From: Eric W Gray <[email-masked]>
Date: Thu, 13 Apr 2006 11:42:40 -0400

Let me answer just the first part of this and let the rest take care of 
itself... :-)

LSPs are [terminated] at aggregation boundaries.  This may not be 
desirable in case of
an all-MPLS network.

To some extent, every box needs to "make up its mind" whether it is a 
router or a switch.
It is important in interoperating between boxes that they are each 
self-consistent.

The aggregator router could decide not to aggregate routing 
information.  That way, it can
distribute more specific labels and not worry about inconsistencies 
between the routes it
has advertised and the labels it distributes.

However, there are reasons why routers aggregate routing information, 
and I think it may
be difficult to justify why those reasons would not apply equally well 
to label distribution.

It may very well be the case that routing aggregation is not completely 
justified in specific
deployment scenarios. In that case, perhaps it would simply be better to 
"turn off" route
aggregation.

--
Eric

Raveendra Torvi wrote:

> Eric,
> According to your solution  LSPs are broken at the aggregation 
> boundary or IGP area boundary, which may not be desirable in case of 
> all-MPLS network. If main goal is to carry transit traffic by the way 
> of LDP-MPLS switching , In case of all-MPLS networks an operator would 
> like to inject only LDP-FECs in other areas (hence achieve the 
> scalability) or avoid summarization LDP-FECs at IGP area boundary .. 
> Please help me understand.
> Ravi.
>
>
> On 4/13/06, Eric W Gray <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Bruno,
>
>         No, if anything specific had to be said, it would be that Ru
>     MUST NOT advertise a more
>         I cannot speak - obviously - for every implementation out
>     there, but here's how I believe
>         o   The ABR-LSR is then the egress for the corresponding
>     LSPs,  in those
>               cases where it has downstream routing entries
>     corresponding to more
>               specific routes.
>         o   The ABR-LSR MAY - at that point - inject arriving packets
>     on downstream
>               LSPs - after it performs a routing look-up and discovers
>     an FTN (thus
>         As I mentioned to Pranjal, this is defined this way for
>     scalability reasons.  It is not the
>     intention of MPLS generally to eliminate the need for routing
>     capability in the network at
>     a cost of introducing unscalably large numbers of label
>     distributions throughout the same
>     network.
>
>         Just as an  opinion, a device that is incapable of making this
>     kind of routing decision,
>>     <>presumably the only thing at issue is Ru should label an IP
>>     packet that it receives.
>
>>[email-masked] <mailto:[email-masked]>
>[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 13 Apr 2006 14:03:35 -0400

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

How does Ru know whether Ruu wants or needs this? 

Bruno> what is the  difference, from the FIB point of  view, between one /30
Bruno> pointing  to Rd  and four  /32 pointing  to Rd?   I believe  some FIB
Bruno> implementation already represent a /30 as four /32 

Do they also represent a /8 as 16,777,216 /32s?  ;-) I'm not sure we want to
require such an implementation. 

The issue is not the size of  the FIB, it's the complexity of the procedures
used to maintain the FIB.  

Bruno> if populating the  FTN with specific FEC is found to  be an issue, we
Bruno> can only populate the ILM on all P routers.  

I don't think the issues are any different.

Bruno> For PE/ingress router, all we really need is BGP to be aware of these
Bruno> LSPs and be able to use them to reach the BGP Next Hops

I don't think that's a simplification.  But if that's what you want, why not
use RSVP-TE to create a tunnel to each potential BGP next hop?  

The underlying  issue in the L3VPN  application is, I  think, the following.
The  bottom label of  an L3VPN  data packet  has to  correspond to  a VPN-IP
route.  The  label above that has to  correspond to the router  which is the
BGP next  hop for that VPN-IP  route, i.e., it  has to correspond to  a /32.
Typically the IGP is made to carry /32 routes for anything that could be the
BGP next hop of  a VPN-IP route.  The worry is that  ultimately there may be
so many of  these that the IGP does  not scale well enough to  put all these
/32s in the FIBs of the P routers.  In that case, I don't think the solution
is to find some  other, more complex way to put all the  /32s in the FIBs of
the P routers.   I don't think that having a more  complicated way to handle
the same amount of information is going  to get us very far.  What we really
want is a hierarchical  solution, in which a third label is  used to get the
packets to a point where the second label is known.