The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

curtis,

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, December 18, 2002 5:08 PM
> To: Shahram Davari
> Cc: 'curtis@fictitious.org'; 'Kireeti Kompella'; 'Gray, Eric';
> 'mpls@UU.NET'
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> In message 
> <4B6D09F3B826D411A67300D0B706EFDEB03BB7@nt-exch-yow.pmc-sierra.bc.ca
> >, 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
>