The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] New TTL Draft
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:puneet@pluris.com] >> Sent: Friday, February 23, 2001 4:53 PM >> To: 'Eric Gray' >> Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >> 'bsd@cisco.com'; Shahram Davari; Bora Akyol >> Subject: RE: New TTL Draft >> >> >> Eric, >> >> Comments inline. >> >> >-----Original Message----- >> >From: Eric Gray [mailto:eric.gray@sandburst.com] >> >Sent: Friday, February 23, 2001 9:34 AM >> >To: Bora Akyol >> >Cc: akyol@akyol.org; djiang1@lucent.com; B, Prakash K (Prakash); >> >'mpls@uu.net' >> >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 >> > >> > |
|