The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDEB03BB6@nt-exch-yow.pmc-sierra.bc.ca
> > I trust this list is here not because these things haven't already
> > been answered but as a reminder to put them in the doc.
> 
> 1, 2, 4, 5 haven't been answered.

4 and 5 were deferred.

> > > 1) In L2VPN or L3VPN do we need to push both inner and outer label?
> > > if not then do people agree to add the inner label to the FEC TLV?
> > 
> > Depends on which LSP you are testing.  Is the inner label semirandom
> > payload to exercise load split or is it the LSP actually under test.
> 
> I want to test the inner LSP. Do I need to push both labels? or only the
> transport label? In case I push both labels there is no way to detect
> the ping packet at the egress. So my suggestion was to only push
> the top label and add the inner label to the echo-request.
> (This point was also raised by Eric Rosen)

My interpretation is push both labels.  Both start at TTL=1.
Increment top, then next label.  If they both terminate at the same
egress LSR (normal for BGP VPN) then bottom TTL never gets past 1.

> > > 2) How do we return the label mapping TLV in case RSVP-TE is used
> > > for the return path? (no such object is defined for RSVP-TE)
> > 
> > According to the instructions in section 5.  Use the RESV.  Add the
> > object specified in the doc.  What's not clear?
> 
> Section 3.2 describes something called Downstream Mapping TLV. This
> is defined for IP packets only. When the return path is the RSVP-TE,
> how does the downstream mapping gets encoded in RESV message? May be the
> answer is trace-route has no value when the return path is RSVP-TE ! or
> may be a Downstream mapping Object needs to be defined.

Downstream is in the forward direction so this question doesn't make
sense.

The Downstream Mapping TLV never refers to the return path.

<snip to end - 4&5 in another message>

Curtis