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, As I had briefly mentioned in reply to Eric's earlier email on the Pop issue, we do not perform a "Route and a Pop" - that is actually treated as a "Route and a PHP". To quote from our ttl draft section 2.4: "For packets that are routed as MPLS, we have three cases" the semantics of "routed as MPLS" implies that any egress Pops have already been performed. If you think that this was unclear in the draft then I will clarify it. Some more comments inline. -Puneet >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Tuesday, February 27, 2001 12:59 PM >To: 'Puneet Agarwal'; 'Eric Gray' >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >'bsd@cisco.com'; Bora Akyol >Subject: RE: New TTL Draft > > >Hi Puneet, > >I can't follow your reasoning. Let me explain what I am trying to say: > >If an egress router is the terminating point of a pipe/uniform >tunnel, then the egress router must pop the top label and >forward the packet using the label (or IP header) that is >beneath the popped label. My question is: What TTL is encoded >in the forwarding label (or IP header). The answer is: oTTL, >which is equal to oTTL= iTTL-1, in which iTTL determination >depends on the tunnel model and is described in section 2.3. > >So my suggestion is to add another bullet (say bullet 4) to >section 2.4, that says: > >4) Pop : This is the terminating point of an LSP tunnel, in >which, first the top label is popped and then the packet is >forwarded based on the lower label (or exposed IP header). The >TTL of the forwarding label (or IP header) is set to: > >oTTL = iTTL-1 > >in which, iTTL is determined based on the type of tunnel >(i.e., uniform/pipe) as explained in section 2.3. I would be happy to include the text with a few modifications: 4) Pop : This is the terminating point of an LSP tunnel, in which, first the top label is popped and then the packet is forwarded based on the lower label (or exposed IP header). Note that this operation can occur recursively. The iTTL is updated as explained in section 2.3. The outgoing TTL would be determined by the last non "Pop" operation performed on the packet. Would such a text address your concerns? -Puneet > > >Yours, >-Shahram > >> -----Original Message----- >> From: Puneet Agarwal [mailto:puneet@pluris.com] >> Sent: Tuesday, February 27, 2001 3:09 PM >> To: Shahram Davari; 'Eric Gray' >> Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >> 'bsd@cisco.com'; Bora Akyol >> Subject: RE: New TTL Draft >> >> >> Hi Shahram, >> >> Based on the tunnel mode definitions in the -07 version of >> mpls-diff draft, >> the oTTL determination is not needed explicitly for the "Pop" >> case. After >> you perform "Pop" (recursively), you need to route (determine >> the egress >> interface etc) the exposed header (IP packet or label). You >> never "Pop" the >> label you route on - you can only SWAP, SWAP+Push or PHP >> (+Push) the label. >> >> Hence I never added the bullet for "Pop" when determining >> oTTL as it is not >> a legal operation. If you want, I can add text in section 2.4 >> of the draft >> that a "Pop" is not a legal operation for a label we route >> on. Would that >> help? >> >> Hope this clarifies. >> >> -Puneet >> >> >-----Original Message----- >> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >Sent: Tuesday, February 27, 2001 11:19 AM >> >To: 'Puneet Agarwal'; 'Eric Gray' >> >Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com'; >> >'bsd@cisco.com'; Bora Akyol >> >Subject: RE: New TTL Draft >> > >> > >> >Hi Puneet, >> > >> >Thanks for your reply. Please see my comments in-line: >> > >> >> >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. >> >> > >> > >> >As you know there are at least 2 distinct operations that >are needed >> >for TTL processing: >> > >> >1) Determining iTTL >> >2) Determining oTTL >> > >> >Section 2.3 describes the iTTL determination for both PHP and >> >non-PHP case. >> >Section 2.4 however describes the oTTL determination for PHP >> >case only. I >> >can't see anywhere in the draft that talks about oTTL >> >determination for non-PHP >> >case. Do you see any? >> > >> > >> >Yours, >> >Shahram >> > >> > |
|