Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Wed, 18 Dec 2002 14:21:11 -0800

curtis,

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Wednesday, December 18, 2002 5:08 PM
> To: Shahram Davari
> Cc: [email-masked]'; 'Kireeti Kompella'; 'Gray, Eric';
> [email-masked]'
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> In message 
> <[email-masked]
> >, Shahram Davari writes:
> > Cusrtis,
> > 
> > For point (5) I already suggested (in previous emails) a 
> change to the Downst
> > ream mapping TLV as following:
> > 
> > To support ATM (28-bit VPI/VCI) and FR (10-bit or 23-bit DLCI)
> > may I suggest changing the size of the Downstream label to 
> 28 bits and 
> > right justifying any ATM/FR/MPLS label in this field as following:
> > 
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                   Downstream IPv4 Router ID         
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |               MTU             | Address Type  |  
> Reserved     |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                   Interface Address                 
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |               Downstream Label                      
>   |Protoco|
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       .                                                     
>           .
> >       .                                                     
>           .
> >       .                                                     
>           .
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |               Downstream Label                      
>   |Protoco|
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> 
> 
> That doesn't help if the ATM LSRs don't decrement TTL.  Did this
> change?  Are ATM LSR decrementing TTL these days?
> 
> The people most interested in MPLS-ping are those people operating
> networks.  The intersection of the set of people operating networks
> and the set of people interested in ATM LSR might be the null set.
> 
> But if adding this TLV makes satisfies the set of people interested in
> ATM LSR, then its fine with me to add this as the Downstream ATM
> Mapping TLV.

Agree with you. Since TTL is not decremented by ATM/FR LSRs, then
you can't presumably run any trace-route on them. So I retract my
suggestion.

> 
> 
> > For point (1) I suggested adding the inner label to the 
> echo-request:
> > 
> > 
> >  0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                      Route Distinguisher            
>           |
> >       |                          (8 octets)                 
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         IPv4 prefix                 
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       | Prefix Length |                 Must Be Zero        
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                  PW/PSN  Label                |  
> Must be Zero |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                      Route Distinguisher            
>           |
> >       |                          (8 octets)                 
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         IPv6 prefix                 
>           |
> >       |                                                     
>           |
> >       |                                                     
>           |
> >       |                                                     
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       | Prefix Length |                 Must Be Zero        
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                  PW/PSN  Label                | 
> Must be Zero  |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> IMHO - That wasn't necessary and its redundant since the next label is
> on the label stack and there is an entry on the FEC stack as well.

A) In ping mode the egress LSR would in fact not look below the inner
label and will forward the ping packet to the customer.
B) In you trace-route example how do you know that you have reached the
egress LSR? Since you may not know that, it is possible to increment the
TTL of top label beyond the egress LSR and cause the ping packet to be delivered
to the customer.

So the inner label should not pushed for LSP-ping packet. Again my suggestion
is to only push the transport label and encode the inner label in the
echo-request message.

-Shahram

> > -Shahram
> Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Dec 2002 17:56:32 -0500

In message <[email-masked]
>, Shahram Davari writes:
<snip>
> label and will forward the ping packet to the customer.

That was the point of the discussion that Alia started a while ago on
"S" bit handling and/or TTL expire on the TTL=1 labels.  The "S" bit
would never be clear on a PW label except MPLS ping.

> TTL of top label beyond the egress LSR and cause the ping packet to be delive
> red to the customer.

I'll send that question to the authors.  

I'll give my guess.  For the common case where the LDP and PW labels
terminate at the same router send return code 3 "Replying router is an
egress for the FEC".  Its not clear what you do for the case where the
top label is popped but other FECs in the label stack continue.  One
clue for the ingress is that the responding router address is equal to
the top "RSVP IPv4 Session" IPv4 tunnel end point address.

It would help to have a stack of "FEC Egress Reached" TLV in the Echo
Reply so the ingress has a clear indication that it is time to take a
FEC TLV off the top of the FEC stack before incrementing TTL.

> is to only push the transport label and encode the inner label in the

The set of labels is supposed to match the FEC stack.  If you just
wanted to confirm the path the transit LSP, then optionally add the
next label but don't include the next FEC.  If you want to confirm the
next label, you must add that label and add that FEC.  If you don't
add the label, at a MP branch point your packet may take a different
path than the VPN label you intend to test for label based MP.

Curtis