Subject: RE: New TTL Draft

From: Puneet Agarwal <[email-masked]>
Date: Thu, 1 Mar 2001 19:15:58 -0800

Eric,

Thanks for your comments. My comments are inline.

-Puneet
[...]
>
>From the draft:
>
>>   This document describes TTL processing in hierarchical MPLS 
>>   networks. We believe that this document adds details that have not 
>>   been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods 
>>   presented in this document complement [MPLS-DS].  
>
>
>I think  it would be helpful for  the draft authors to  say 
>explicitly where
>this draft:
>
>1. corrects errors in the RFCs
>
>2. modifies the functionality specified in the RFCS
>
>3. adds new functionality not specified in the RFCs
>
>4. adds details to clarify what is specified in the RFCs. 
>
>That  is, let's  try to  make sure  that we  all agree  about  
>what changes/
>additions are being proposed, and why. 
>
>It is true that the RFCs are not very clear about the way to 
>handle the case
>where one doesn't  want to percolate the TTL through  the 
>label stack ("pipe
>model"?).

This is a good point. We will add this to the next revision of the draft.
Briefly, the draft addresses TTL issues related to Pipe mode tunnels,
hierarchical tunnels (any mix of pipe/uniform) and TTL processing for PHP -
these in our opinion have not been specified in any another 
draft/rfc. TTL processing for non-hierarchical uniform model LSPs are
generally covered in [MPLS-ENCAPS] but restated in the current draft for
completeness and clarity. 
 
>
>Whether the "pipe model" and the "uniform model" always (or 
>ever) need to be
>distinguished through signalling is  another matter.  Is the 
>assumption that
>a service provider might make a different decision for every 
>individual LSP? 
>(In the case  of "ordinary" LDP, I think this is  somewhat 
>unlikely, and the
>signalling unnecessary.) 
>

It is hard for me to comment on how varied the service provider deployments
might be. It is unlikely that a provider would have different model LSPs
within their own networks but should we restrict him/her from doing so by
not providing the appropriate signaling mechanisms?

-Puneet

---

From: Eric Rosen <[email-masked]>
Date: Fri, 02 Mar 2001 10:57:06 -0500

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.