The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Mar> msg00040



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

New TTL Draft

  • From: Eric Rosen <erosen@cisco.com>
  • Date: Fri, 02 Mar 2001 10:57:06 -0500
  • cc: Bora Akyol <akyol@pluris.com>, akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" <prakashk@lucent.com>, "'mpls@uu.net'" <mpls@UU.NET>
  • User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1(Nishinokyō) Emacs/20.6 (sparc-sun-solaris2.5.1)MULE/4.0 (HANANOEN)


Puneet> Briefly,  the  draft  addresses  TTL  issues related  to  Pipe  mode
Puneet> tunnels,  hierarchical tunnels  (any  mix of  pipe/uniform) and  TTL
Puneet> processing for PHP - these in our opinion have not been specified in
Puneet> any another draft/rfc

It seems to me that for the uniform model, this is covered in section 2.4 of
RFC 3032. 

Puneet> It  is unlikely  that a  provider  would have  different model  LSPs
Puneet> within their own networks but  should we restrict him/her from doing
Puneet> so by not providing the appropriate signaling mechanisms?

Yes. 

If we think  a signaling mechanism is unlikely to be  used, there's not much
point in having it.  (It is true  that the MPLS specs are full of stuff that
is unlikely  to be used,  because the WG  couldn't reach consensus  on which
things are likely and which are  unlikely.  But I'm not sure that's the case
here.) 

Also,  there  is an  impact  in  the forwarding  path  if  we  make the  TTL
processing  more  complex than  it  needs to  be,  by  adding more  optional
behaviors.

  • References: