The MPLS WG Archive

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

My machine seems to have lost the end of my last message...

And not yet covered is:

1) removing one way mode

2) MTU handling

And we seem to be close on using the FEC stack to infer appropriate return
path. This (with a few other tweaks) may permit us to trace PWs. If we add
the "reply to" TLV, we can also traceroute VPN traffic across the PSN. 

Start with a traceroute originating at a PE with a FEC stack containing a
VPN FEC, a PSN FEC, a label stack with the VPN label, and PSN label, an IP
header with a customer address pair corresponding to the flow of interest,
and a "reply to" TLV with the PE's PSN address. When TTL exhausts at a P
router, the packet so far had been forwarded exactly as the particular
customer flow would have been forwarded, and the P router can infer that the
"reply to" address is a PSN address due to the presence of the PSN FEC in
the FEC stack.

This gets me what we wanted with the ECMP extensions to LSP-Query, a means
of determining where customer flows go. Truly ugly layer violation in
spades, but I'm not going to squawk at this point ;-)

However we also need some rules if we add "return to", like no use of all
routers multicast address, or subnet broadcast (among others) ;-)... Looking
at the draft, some text is required in the security section anyway such as,
"prior to replying to an echo request, the recipient needs to ensure the
address of origin is a unique and reasonable routable address (and if not to
silently discard the echo request)." I'm sure others can do better on the
wordsmithing, but you get the idea.

cheers
Dave




> 
> > -----Original Message-----
> > From: George Swallow [mailto:swallow@cisco.com]
> > Sent: Thursday, February 12, 2004 12:59 PM
> > To: Allan, David [CAR:NS00:EXCH]
> > Cc: 'kireeti@juniper.net'; mpls@UU.NET; swallow@cisco.com
> > Subject: Re: Comments on LSP Ping 04 
> > 
> > 
> > Dave -
> > 
> > > The reason I suggested the text is that there is a converse
> > situation
> > > to what you underlined where you can have more labels in the stack
> > > than FECs if you insert the PING (for example) in an LDP 
> > network, and
> > > due to uniform mode TTL handling, a traceroute terminates in a TE
> > > trunk then the P LSR in the trunk has no knowledge of any 
> > FECs in the
> > > stack.
> > 
> > Correct.
> > 
> > > The procedure as described
> > > will break.
> > 
> > Could you explain how?  I'm not seeing a problem.
> > 
> > > On item 4, my reason for saying the FEC stack has limited
> > utility in
> > > traceroute mode is that when tracing a VPN or PW, the P
> > LSRs have no
> > > knowledge of the VPN or PW FECs anyway, and the processing
> > rules would
> > > halt on matching the first FEC in the stack. So as written,
> > the extra
> > > FEC stack elements would not be examined at LSRs where TTL
> > exhausts.
> > > ergo, not really useful.
> > 
> > Yes, but you should never get that far if things are working
> > properly. If you have 
> > 
> >      FEC Type     Label Stack    FEC Stack
> > 
> >      TE                57           ...
> >      LDP               22         10.10.10.10
> >      VPN               45         192.27.168.1
> > 
> > Then the rules say look at first label.
> > 
> > In step 1. Is there a FEC (stack entry) corresponding to
> > this label etc, if not go to step 4.
> > 
> > Then you find that you are label switching at depth 3.  The
> > originator of the ping will be notified that you are doing 
> > something at a layer below 
> > 
> > I'll make it clearer that you are looking for a stack entry
> > in step one.  In step 4 if you can determine the label 
> > operation, ostensibly you also know that the label is valid 
> > on the interface and what the FEC is (although this last 
> > piece is not really necessary for the processing)
> > 
> > ...George
> > 
> > ==============================================================
> > ==========
> > George Swallow             Cisco Systems                  
> > (978) 936-1398
> >                            1414 Massachusetts Avenue
> >                            Boxborough, MA 01719
> > 
> > 
>