Subject: [MPLS-OPS]: Re: Prefix Mismatch

From: "wu min" <[email-masked]>
Date: Fri, 19 Apr 2002 14:51:34 +0000

Hello again,

> > Questions:
> > ----------
> > 1. Does it mean R2 has to terminate LSP for FEC with 10.2/16 address 
>prefix
> > by means of stripping the top label (the only label) and look into IP 
>header
> > to determine its finer FEC and then label the packet again with the
> > appropriate outgoing label. Is this true?
>
>My understanding of the RFC is the LSP for 10.2/16 stops at R2.  The
>the packet may or may not be label switched after R2.

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?

> > 2. Suppose the LSP is being used as a tunnel that ends after R2 and if 
>the
> > answer for my question (1) is true, then stripping the top label will 
>never
> > reveal the IP header yet since there will still be 1 or more labels. Is 
>this
> > situation valid? If so, can R2 still manage to terminate the LSP and 
>perform
> > best match algorithm? If yes, then how?
>
>I don't think you can build an LSP beyond R2 in this case, in another
>word, I don't know how you can have a tunnel that ends after R2.

What I meant is, take for example an LSR with address 10.2.153.178 is a 
remote peer and the LSP in the example is the hop-by-hop routed tunnel used 
for this peering. Obviously here the LSR is after the LSR2.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

---

From: "wu min" <[email-masked]>
Date: Wed, 24 Apr 2002 00:49:45 +0000

Hi Zidan,

Please see my text below following your comment.

>wu min wrote:
>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