The MPLS WG Archive

["wu min" <made_in__china@hotmail.com>]

Hi Zidan,

Please see my text below following your comment.

>wu min wrote:
> >
> > The last few lines of the RFC3031 snippet from my previous message 
>reads,
> > "....In this situation, packet P can be label Switched until it reaches 
>R2,
> > but since R2 has performed route aggregation, it must execute the best 
>match
> > algorithm to find P's FEC."
> >
> > It indicated that the best match algorithm must be executed to find the 
>next
> > appropriate FEC to be used for further label switching. In my opinion,
> > surely this does not stop it from label switching further, right?
> >
>
>Yes, it is true that it does not stop it from being "switched" from R2,
>but you will have TWO (2) LSPs involved in this case.  The LSP_1 stops
>at R2, and LSP_2 starts at R2.  When the packet is processed at R2,
>it is NOT a simple label swapping, there is route lookup or label
>pushing involved if necessary.

Great! We've come to common understanding now. We both agree that R2 stop 
switching, but handle packet at layer 3 instead to figure out how to forward 
it (as explained in RFC3031). Let's come to the scenario that I have been 
trying to convey:

Given that R0 is a label distribution peer to R1 and R1, R2 and R3 are 
connected and configured as the previous example. Let R3 advertises to R2 
the three different prefixes and R2 advertises to R1 the aggregation of 
those prefixes exactly as what are described in the previous example. Let R1 
advertises to R0 address prefix 10.2/16 (the only prefix that it got from 
R2). Now assuming that R0 initiates remote peering with another router Rn 
which has an address that falls within the range of one or two of the 
prefixes, say 10.2.153.178. Additionally, R0 has chosen not to initiate 
'explicitly routed tunnel' to Rn when engaging in remote peering but rather 
depends on 'hop-by-hop routed tunnel' that naturally formed through routing 
information. Obviously here, the tunnel is the LSP that is formed by the FEC 
address prefixes advertised. This is illustrated below:

                          10.2.153/23
                          10.2.154/23
         *10.2/16           10.2/16
    R0------>R1----->R2------->R3---...-->Rn
*10.2/16         *10.2/16
               (10.2.153/23)
               (10.2.154/23)

The address prefix(es) shown at each node are those received from individual 
successive neighbouring peer. The asterisk that precedes an address prefix 
indicates the FEC for the LSP that is used as tunnel. Since R2 aggregates 
the prefixes (shown in brackets) into 10.2/16, thus the LSP stops there. In 
this case R2 must pop label and process every packet that originated from 
the LSP at layer 3 for further forwarding decision. Note that the LSP 
termination at R2 is not known to R1 and R0. From R0 standpoint, the LSP 
continues beyond R2 until Rn. Since the LSP is used as tunnel by R0, every 
'tunneled packet' will have 2 labels. When R2 received this tunneled packet, 
it will pop the outer label as a normal process to inspect IP header for 
further forwarding decision. However this will definitely fail since there 
is still an inner label. Furthermore, the IP address will not contain Rn 
address, but its ultimate destination address which may not fall within the 
given prefixes' range. Even R2 awares (which will never happen) of the 
second label, the IP header information is not valid at least in the context 
described in the RFC.

The example given in the RFC involves a normal packet forwarding with a 
single label. This will not cause any problem at R2 since label popping will 
immediately reveals the IP header and the IP destination address will match 
one or more of the prefixes. But in the tunnel case, it would fail.

Here I am not sure my tunnel example is valid or not. If it does, then how 
does R2 overcome this?

-Tze Ven



_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com