Subject: New TTL Draft

From: Francis Arts <[email-masked]>
Date: Sat, 03 Mar 2001 15:55:31 +0100

Hello Eric,

In the discussion below you propose the possibility to decrement the TTL
with N units. You indicate that the reason for doing this, is the
following:

> > >    There are practical reasons for decrementing TTL by more
> > >than one (a high-cost or low-bandwidth link, for example)
> > >when it is desirable to accelerate the aging of possibly looping
> > >packets.  A higher TTL decrement punishes all packets that use
> > >the link, but it punishes looping packets much more.
>

High-cost and low-bandwidth links should be used carefully in a network.
But why would one like to accelerate the aging for packets received on a
high-cost or low-bandwidth link?

Kind regards,

    Francis.

--------------

http://cell.onecall.net/mhonarc/mpls/2001-Feb/msg00316.html
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New TTL Draft

From: Puneet Agarwal <[email-masked]>

Date: Mon, 26 Feb 2001 15:00:17 -0800

Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Bora Akyol <[email-masked]>

Hi Shahram,

Thanks for your comments. My comments are inline.

-Puneet

>
>Hi Puneet/Eric,
>
>1)You are right we have not described how to signal Pipe/short
>pipe/uniform models. Since our draft is in its last call and
>can't be changed substantially, I propose that we get together
>to write a separate I-D to address the CR-LDP/RSVP-TE
>extensions for signaling the tunneling model.

Agreed. We can take this up privately with each other.

>
>2) Section 2.4 does not discuss an important case that is:
>egress processing of tunnels, i.e. pop and forwarding the
>packet as MPLS.

Pop (or Egress Pop to distinguish from PHP) is actually covered in section
2.3. The possibly operation when forwarding the packet as MPLS are covered
in the 3 bullets of section 2.4. Combine section 2.3 and the relevant
section of 2.4 and I think your concern about the missing case should be
answered. Hence as far as I can see the case is convered, but please let me
know if you still think that it is not addressed.
>
>3)As you may know, version -08 of our draft has introduced two
>types of Pipe tunnels a) Short pipe and b) Pipe. The short
>pipe is what was called the "pipe" in version -07. But the new
>"pipe" model is a bit different, in the sense that all the
>egress processing is done based on top label. So your
>description of TTL processing for the pipe model remains valid
>for "short pipe" (except that you need to describe the egress
>processing too, see bullet 2 above), but you need to define
>another TTL processing rule for the "pipe", which is: the top
>label TTL is decremented and checked, while the lower label
>TTL (unchanged) is used for forwarding the packet.

We had based our draft on -07 version of the mpls-diff draft. I will take
into account the -08 version (where the new model nomenclature was
introduced) and update our spec accordingly.

-Puneet
>
>Yours,
>-Shahram
>
>
>
>
>> -----Original Message-----
>> From: Puneet Agarwal [mailto:[email-masked]]
>> Sent: Friday, February 23, 2001 4:53 PM
>> To: 'Eric Gray'
>> Cc: [email-masked]'; [email-masked]'; [email-masked]';
>> [email-masked]'; Shahram Davari; Bora Akyol
>> Subject: RE: New TTL Draft
>>
>>
>> Eric,
>>
>> Comments inline.
>>
>> >-----Original Message-----
>> >From: Eric Gray [mailto:[email-masked]]
>> >Sent: Friday, February 23, 2001 9:34 AM
>> >To: Bora Akyol
>> >Cc: [email-masked]; [email-masked]; B, Prakash K (Prakash);
>> >[email-masked]'
>> >Subject: Re: New TTL Draft
>> >
>> >
>> >Bora/Puneet,
>> >
>> > Some comments.
>> >
>> > In section 2.4, item 3 - PHP does not necessarily expose an
>> >IP header. The text in this section is not clear in this respect
>> >- possibly because of the textual construct "IP-Header/label".
>> >It might be somewhat clearer if you use "header" and add a
>> >paragraph stating that the PHP exposed header may be either
>> >an IP header or an MPLS label and the appropriate oTTL is
>> >written to the corresponding TTL field of this PHP exposed
>> >header.
>>
>> I agree. We will change the wording in the next rev of the draft.
>> >
>> > Also, in this section, why is oTTL set to the TTL of the
>> >exposed header if it is not used for anything?
>>
>> Good point. We do not need to set this. This was a leftover
>> from some text
>> we took out of section 2.5 at the last moment that used this
>> information. We
>> will fix this in the next rev.
>> >
>> > In addition, if your actually specifying a behavior (rather than
>> >an architecture), I believe you need to allow that the TTL may
>> >be decremented by a number other than one. RFC 791 states
>> >that RFC is decremented by at least one. Your draft states in
>> >several places that iTTL is decremented (I assume that the
>> >underscore in these cases is meant to be a minus sign) by one.
>>
>> The underscore is indeed supposed to be a minus. Will be
>> fixed in the next
>> rev.
>> I have no problems in allowing the iTTL to be decremented by
>> more than one.
>> I will change the text to state that the iTTL should be
>> decremented by "N",
>> where "N" is user configured and is greater than 0. The
>> default value of "N"
>> should be 1.
>>
>> >
>> > There are practical reasons for decrementing TTL by more
>> >than one (a high-cost or low-bandwidth link, for example)
>> >when it is desirable to accelerate the aging of possibly looping
>> >packets. A higher TTL decrement punishes all packets that use
>> >the link, but it punishes looping packets much more.
>> >
>> > Finally, what is the mechanism which the PHP uses to determine
>> >whether or not the LSP is using the pipe or the uniform model? I am
>> >not sure this information is currently available.
>>
>> You may be right. I looked through
>> "draft-ietf-mpls-diff-ext-08.txt", but
>> did not see any method to signal the model (pipe or uniform)
>> associated with
>> the LSP, using either RSVP or LDP. If it is a missing piece,
>> then I hope
>> that it will be addressed by the authors of that draft.
>>
>> -Puneet
>>
>> >
>> >--
>> >Eric Gray
>> >
>> >Bora Akyol wrote:
>> >
>> >> Note that we (Puneet and I) just posted an Internet Draft on TTL
>> >> handling in hierarchical MPLS networks.
>> >>
>> >> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt
>> >>
>> >>
>> http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt
>> >>
>> >> We welcome any comments,
>> >>
>> >> Bora Akyol
>> >
>>
>

Prev by Date:
New Internet Draft on ERO

Next by Date:
New Internet Draft on ERO

Prev by thread:
New TTL Draft

Next by thread:
New TTL Draft

Index(es):

Date

Thread

---

From: [email-masked]
Date: Wed, 7 Mar 2001 10:29:30 -0000

Hi Satoru,  Thanks for your response/observations....please see answers and
further comments below:

S.Matsushima [mailto:[email-masked]] wrote on 07 March 2001
04:44:
> > 1	I agree with the '1-hop' concept in here since it is 
> architecturally
> > correct.  That is, if one creates a trail at layer N say, 
> then each link
> > connection in that trail (ie between 2 adjacent nodes at 
> layer N) is created
> > by a server trail at layer N-1.  This process recurses for 
> the layer N-1
> > trail and so on to the duct.  In other words, a trail at 
> layer N has no
> > visibility, and indeed should not have visibility, of all 
> the constituent
> > server layers (which may also be different technologies) 
> that lie underneath
> > it.  Hence, from a client layer perspective a link 
> connection can never be
> > anything but a single hop, and the TTL setting of each 
> trail should be an
> > independent consideration.
> 
> Thanks, I agree too.
> I think we need to more carefully describe TTL processing on
> layerd(hierarchical) environment.
NH=> This is true.  An obvious example of why virtualisation of lower layer
topologies is important is the case of protection-switching/restoration.
Here, the restored link connection at layer N say is still 1-hop (from the
perspective of that layer), but the *new* trail (ie the new prot-switched
LSP) at layer N-1 is likely to have a new number of hops (ie link
connections) at layer N-1.  There is no reason why the layer N LSP should be
aware of this, and from a layered architectural perspective indeed it should
not.
> 
> > 2	Wrt to detecting defects that can affect LSPs please 
> check out the
> > ID that was just posted (by Shahram) on MPLS OAM.  Note 
> that this is aimed
> > at explicitly routed pt-pt LSPs and not plain LDP LSPs.  
> > http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt
> > I hope you find this of some value.
> 
> I have just read your draft. I think this OAM method should be have
> each LSR to detect LSP defect. Is it right?
NH=> It depends on where the defect is originally sourced.  If it comes from
a layer network *below* the MPLS fabric (eg SDH) then the 1st LSR downstream
of the server (SDH) failure will be informed of the server failure (by an
FDI signal....AIS in SDH say) and so the defect will be detected, and
propagated via server(SDH)->client(MPLS) adaptation, from that LSR upwards
(into all affected LSPs in a recursive manner as explained in the draft).
If however the defect is sourced from within the MPLS fabric (so this could
be a simple break, mismerging, swapped LSPs..) then this will *only* be
detected at the LSP trail termination point of the lowest LSP affected (by
the appropriate aberration of the CV flow).  LSRs *before* the LSP sink
point of this lowest layer LSP will not detect such a defect......this is
correct architectural behaviour.  Obviously all higher client layer LSPs (of
the lowest LSP affected) which span the failure will also be affected, and
this is the point of why the FDI has to propagate upwards through the
relevant server->client adaptation points (at LSP sinks) to stop alarm
storms....which could be geographically/organisationally distant from the
original failure point.

> Our "KeepAlive" does not depend on particular method. It  depend
> on "1-hop" method and IP as compared with OAM.(Is it CCAMP charter?)
NH=> I am not sure which WG should deal with this.....but OAM is an
intrinsic function of any layer network technology that should be addressed
by whoever is specifying that technology.  The difference between our
methods is that yours addresses LSP link connections (ie below MPLS fabric
defects only) whereas our OAM work takes the trail perspective (ie between
LSP source and sink) and also adds some extra defect handling and diagnostic
capabilities....as indeed you note in the line directly below here:
> And OAM has some useful function.(FDI,BDI,P)
> 
> But I think all of the MPLS signalling depend on IP, so "KeepAlive"
> does not cause more problem(ie interoperability issue).
NH=> I see no interoperability issues either.
<snipped to end>