The MPLS WG Archive

["Sharma, Prem" <p_sharma@trillium.com>]

Hi Wu Min,

Some comments inline:

>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?
> >
>
>Sure, if there is another LSP built for the more granular FEC, but you
>don't know if there is one or not.

>Do you mean 'more granular FEC' = 'finer granularity'? If you mean that, 
>then R2 should have known there exists such FECs since R3 advertised 
>10.2.153/23 and 10.2.154/23 prefixes to it. I am not sure whether I 
>understand your comment correctly. Please clarify.

[PREM]: Though R3 is advertising these address prefixes but there may or may
not be LSPs for these prefixes going towards R3. These new LSPs (LSPs for
these address prefixes) would originate from R2 and may terminate on or
after R3. 
So, from R1-R2 the labelled data transfer would take place on some LSP let's
LSP1. After the data has been received at R2 (over LSP1), how does the rest
of packet journey will take place till the final destination, is now known.
Should it again go out on some LSP, that LSP would be different from LSP1.
That LSP MAY BE considered a continuation/extension of LSP1 (depending on
system implementation) but in actual protocol sense, the extended segment
will not be part of LSP1.

Now coming to clarification of the following stmts. from RFC 3031, 
...
it must execute the best match algorithm to find P's FEC.
...

This is exactly the same operation that takes place at the ingress node -
classification of the packet and mapping to a particular FEC. So, hopefully
this would be clear now.

-Prem



> > > > 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.
>
>With LDP, you can try to build a tunnel to 10.2.153.178, but if the
>tunnel LSP is broken in the middle, you won't know. If you run MPLS VPN
>over the broken tunnel, you blackhole the traffic.

If you mean 'broken' = 'transparent FEC remapping', then I would agree with 
you. If you mean 'broken' = 'total disconnection' then eventually LSRs at 
both ends of the tunnel would know the tunnel is broken.

Anyway my previous question narrowed down just to R2 only regardless of 
whether LSRs at both ends of the tunnel aware of any 'FEC remapping' at the 
middle of the tunnel or not.

I am just wondering whether R2 would still be able to execute the best match

algorithm to find better FEC for the affected packets since in the 'tunnel' 
case, stripping the top label would not immediately reveal the IP header (R2

will never know whether the LSP is also being used for tunnelling or not), 
but a second level label that it does not undestand at all.

-Tze Ven


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com