From jsmith4112003@yahoo.co.uk Wed Jun 1 06:40:01 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F087FE0791 for ; Wed, 1 Jun 2011 06:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aSc9G+9dnFh for ; Wed, 1 Jun 2011 06:40:00 -0700 (PDT) Received: from nm13-vm0.bullet.mail.ukl.yahoo.com (nm13-vm0.bullet.mail.ukl.yahoo.com [217.146.183.248]) by ietfa.amsl.com (Postfix) with SMTP id C931BE06FC for ; Wed, 1 Jun 2011 06:39:59 -0700 (PDT) Received: from [217.146.183.213] by nm13.bullet.mail.ukl.yahoo.com with NNFMP; 01 Jun 2011 13:39:56 -0000 Received: from [217.146.183.43] by tm6.bullet.mail.ukl.yahoo.com with NNFMP; 01 Jun 2011 13:39:55 -0000 Received: from [127.0.0.1] by omp1028.mail.ukl.yahoo.com with NNFMP; 01 Jun 2011 13:39:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 977417.33492.bm@omp1028.mail.ukl.yahoo.com Received: (qmail 94074 invoked by uid 60001); 1 Jun 2011 13:39:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1306935595; bh=ep1IeXFuMBHE94l0ESxd6Ht1LcT8DWZ9TiVMQ592QLQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QSUSrUH+mvtrUo3wdPXFT6rVKe6OCJzJckDIimEOnpA3mNMOQNc3NEdlmPtgcRdPLLwb/+Kh08+qXL9PP8sPGaQUQepzj5xI8VWNsS32gONxFmkSE2W0HilqggAfMA+fbQGJlAniV7265OOxSPaGJ9lcrke+DZIQUMrn7YSUne8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oQVKnWKh7EBOYIpXeY8lXAv9Z7OqpkByxmEcQgPCB8tJn7J24n+JztxAdyolRvectYW4+d//KkVBNlenujtKuh28OCnBxrNOmZ8G56c85Pk8GSKZsYUvdtfz/BkHjgz3tb5K0EFcWsDPCi7ML9gOdCJHJtKHA18k3EE0edCLDXg=; Message-ID: <813783.91263.qm@web27208.mail.ukl.yahoo.com> X-YMail-OSG: qAcblosVM1lQa3vcjo5jqonq5cpIL3H5XTgNQvR0y3IwXCT ZE2fPpmexUOnvGmhBrBpB6POvy2TxDqIt6Z4Fhru3TTqr5cj3RLxK0Vdews2 joaK4604hA3.rgxiM7GCn7.qNhecHzND3kKgzEOwHfQJZCFt2v5rSJO8S2DC qAog3KkmbttT9FMxVS8Mi.F.I9PmIG7wk1f0w9mArMn3Bq6LD3w8O_5Yadoo m_nTGepBMQs5W4ZjjfeZAOel78F6o5HsyBXtkEXBX.KYOfjNqfJkF3njE4ms E4PRz.pecOT2bexvUBlxBe96AubWMoePnImQJh.uPFD4atzFWdNRIqeQxjIZ uP6SJ.0eTajYFxwKHVWZO1.DALA-- Received: from [135.245.168.34] by web27208.mail.ukl.yahoo.com via HTTP; Wed, 01 Jun 2011 14:39:55 BST X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 References: <917871.15418.qm@web27201.mail.ukl.yahoo.com> Date: Wed, 1 Jun 2011 14:39:55 +0100 (BST) From: John Smith Subject: Re: Different TTLs To: l3vpn@ietf.org In-Reply-To: <917871.15418.qm@web27201.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:40:01 -0000 Would be great if somebody can answer this!=0A=0A=0A----- Original Message = ----=0AFrom: John Smith =0ATo: l3vpn@ietf.org=0A= Sent: Tue, 31 May, 2011 4:27:45=0ASubject: Different TTLs=0A=0AHi,=0A=0AI w= ould like to understand the relation between the TTL carried in the BGP lab= el =0A=0Aand the IP payload in the L3 VPN scenarios. As per my understandin= g it will =0Aalways be the same as IP TTL. Is there any scenario when it wi= ll be different =0Afrom the IP TTL. I understand that there are different m= odels for carrying the =0Atransport TTL. In one model the IP TTL is copied = to the transport label, which =0Ais reduced by each P hop and is finally co= pied back to the IP TTL field at the =0Aegress PE router. In this case the = IP TTL gets decremented by as many hops as =0Aexist in the service provider= network. In another, the TTL of the transport =0Alabel is kept as 255 and = is decremented at each hop. The IP TTL is preserved and =0A=0Athe customer = is oblivious to the service provider topology.=0A=0AIs my understanding of = the two models correct?=0A=0ANow, my question is what do we do about the TT= L carried in the second label (the =0A=0ABGP label)? Should it be kept as 2= 55 or should we copy the IP TTL. Whats the use =0A=0Aof setting any TTL the= re as this label is never exposed (unless someone is using =0A=0Aimplicit n= ull at the egress that is).=0A=0AThanks, John=0A From jsmith4112003@yahoo.co.uk Wed Jun 1 15:47:05 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8EE09B8 for ; Wed, 1 Jun 2011 15:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d0hjdyI05RW for ; Wed, 1 Jun 2011 15:47:04 -0700 (PDT) Received: from nm5-vm0.bullet.mail.ukl.yahoo.com (nm5-vm0.bullet.mail.ukl.yahoo.com [217.146.183.232]) by ietfa.amsl.com (Postfix) with SMTP id 99B55E09B3 for ; Wed, 1 Jun 2011 15:47:04 -0700 (PDT) Received: from [217.146.183.208] by nm5.bullet.mail.ukl.yahoo.com with NNFMP; 01 Jun 2011 22:47:03 -0000 Received: from [217.146.183.175] by tm1.bullet.mail.ukl.yahoo.com with NNFMP; 01 Jun 2011 22:47:03 -0000 Received: from [127.0.0.1] by omp1016.mail.ukl.yahoo.com with NNFMP; 01 Jun 2011 22:47:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 849599.52352.bm@omp1016.mail.ukl.yahoo.com Received: (qmail 23408 invoked by uid 60001); 1 Jun 2011 22:47:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1306968423; bh=Q/pxQtceOj0leNRQYrNGZEcpyA4T3CASyCWB8LiAFdU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5MtsyNzWcVW8xxHT69/+U1qfRx/WbPvlBZV+aFPF89SVDuEqwBtFd025aFiK+C9CkEjtLibKwVDWemU+FWxK38OZ/Y/HikdoFcYugZfF5TygU8I7S6ALt6MRXQTo/hPelcChKO43nYPxNwe675KmyuXpT9GV9DadEmZZhgXaRUY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=skdx29/xIcQz0NIZGvhhFvdWW7QLF23Lg/XYpgFlYtRzS3XwETWdYk6lf6SYteZ6h0F1WB8aE7UF6OJCf/Y6xzsRcnqkp2tdnUaJZrViIHxrWmPr6BouolK5tlUvD03qkt+JbUsgSv8lCRTQnenJPFTYLdePs3RJfWI/fYMW0e8=; Message-ID: <720565.10030.qm@web27207.mail.ukl.yahoo.com> X-YMail-OSG: QIrfLUsVM1kmuwKoj5u1MI3miN4BpWtUOKNKwogcQFEEVtz IZlzP.vxwLXEA460ve8sh90hB6NJ5XRbnbnh5g_dLbVDlJqkJN_P9QjdY7dA XOBrSHP57VSPHrxkzfstERhuYq9KvdpWepuFF6IbGJr35oaksuPPSb0bHFnl rF.uIhJLgiTAQ_Ur0XjQnzpLOu3A69iVI3UHOjxH1ynw8ySU4ljTcJ9KVChc ss6J5LA8Q5tNwzQhBeGltPQEZOI7E9SmXwkKEgGZSpm.EUBC6RDvnZOH_tVp LIu68FnvTBA80T6EYcimpKbg.52rxLw8Qmbo6eqS0alMbz5yI40BCbtYKhPR WGYtit5OTdZAkEuDQ3S.847iPUQ-- Received: from [135.245.168.35] by web27207.mail.ukl.yahoo.com via HTTP; Wed, 01 Jun 2011 23:47:03 BST X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 References: <917871.15418.qm@web27201.mail.ukl.yahoo.com> <813783.91263.qm@web27208.mail.ukl.yahoo.com> Date: Wed, 1 Jun 2011 23:47:03 +0100 (BST) From: John Smith Subject: Re: Different TTLs To: "Don Heidrich \(dheidric\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:47:05 -0000 Don,=0A=0AThanks for confirming this.=0A=0AMy doubt is specifically wrt the= BGP label thats carried in the data packet. =0AWhat TTL should that be set= to? And is it ever modified? Note that the BGP label =0Ais never really ex= posed, unless there is PHP or something. Is the TTL of the =0Ainner label (= the BGP label) set to the TTL as the IP payload? And if Yes, then =0Awill i= t *ever* be different than the IP TTL when it reaches the other remote PE = =0Arouter?=0A=0AThanks, John=0A=0A=0A----- Original Message ----=0AFrom: Do= n Heidrich (dheidric) =0ATo: John Smith =0ASent: Wed, 1 June, 2011 20:43:25=0ASubject: RE: Different TT= Ls=0A=0AJohn,=0A=0AYour assumptions are correct, one way the customer can s= ee and trace the SP =0Anetwork routers, the other the SP network appears as= one hop.=0A=0ARe label TTL - as labels are pushed and popped at various ho= ps the TTL is copied =0Ato the outer label. At the last MPLS router (or pen= ultimate) we have the option =0Ato copy TTL back into the IP header or not.= =0A=0A-Don=0A=0A> -----Original Message-----=0A> From: l3vpn-bounces@ietf.o= rg [mailto:l3vpn-bounces@ietf.org] On Behalf=0A> Of John Smith=0A> Sent: We= dnesday, June 01, 2011 9:40 AM=0A> To: l3vpn@ietf.org=0A> Subject: Re: Diff= erent TTLs=0A> =0A> Would be great if somebody can answer this!=0A> =0A> = =0A> ----- Original Message ----=0A> From: John Smith =0A> To: l3vpn@ietf.org=0A> Sent: Tue, 31 May, 2011 4:27:45=0A> Subje= ct: Different TTLs=0A> =0A> Hi,=0A> =0A> I would like to understand the rel= ation between the TTL carried in the=0A> BGP label=0A> =0A> and the IP payl= oad in the L3 VPN scenarios. As per my understanding it=0A> will=0A> always= be the same as IP TTL. Is there any scenario when it will be=0A> different= =0A> from the IP TTL. I understand that there are different models for=0A> = carrying the=0A> transport TTL. In one model the IP TTL is copied to the tr= ansport=0A> label, which=0A> is reduced by each P hop and is finally copied= back to the IP TTL field=0A> at the=0A> egress PE router. In this case the= IP TTL gets decremented by as many=0A> hops as=0A> exist in the service pr= ovider network. In another, the TTL of the=0A> transport=0A> label is kept = as 255 and is decremented at each hop. The IP TTL is=0A> preserved and=0A> = =0A> the customer is oblivious to the service provider topology.=0A> =0A> I= s my understanding of the two models correct?=0A> =0A> Now, my question is = what do we do about the TTL carried in the second=0A> label (the=0A> =0A> B= GP label)? Should it be kept as 255 or should we copy the IP TTL.=0A> Whats= the use=0A> =0A> of setting any TTL there as this label is never exposed (= unless someone=0A> is using=0A> =0A> implicit null at the egress that is).= =0A> =0A> Thanks, John From stephane.litkowski@orange-ftgroup.com Fri Jun 3 02:42:44 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18BCE0701 for ; Fri, 3 Jun 2011 02:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCKE34EOav5c for ; Fri, 3 Jun 2011 02:42:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 84164E068D for ; Fri, 3 Jun 2011 02:42:43 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C11392641DA; Fri, 3 Jun 2011 11:42:42 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A5D5E35C0D4; Fri, 3 Jun 2011 11:42:42 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jun 2011 11:42:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Different TTLs Date: Fri, 3 Jun 2011 11:42:41 +0200 Message-ID: <14592_1307094162_4DE8AC92_14592_117798_1_4FC3556A36EE3646A09DAA60429F53350675C12E@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <720565.10030.qm@web27207.mail.ukl.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Different TTLs thread-index: AcwgrdliWvSr9P6nQ/q431Sp5ETAvgBI2KKg References: <917871.15418.qm@web27201.mail.ukl.yahoo.com><813783.91263.qm@web27208.mail.ukl.yahoo.com> <720565.10030.qm@web27207.mail.ukl.yahoo.com> From: To: "John Smith" , "Don Heidrich (dheidric)" X-OriginalArrivalTime: 03 Jun 2011 09:42:42.0976 (UTC) FILETIME=[95F74200:01CC21D2] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.3.80616 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 09:42:44 -0000 Hi, Each label level is representing a specific level of tunneling. If you consider Uniform model, and service+transport MPLS, MPLS TTL is set = IP TTL value when PE is doing encapsulation (double push). When penultimate= hop is popping transport label, TTL of transport label is copied back to s= ervice label. When service label is popped, TTL is copied back to IP layer.= =20 If you consider "Short pipe", MPLS TTL is set to 255 when PE is doing encap= sulation (double push). When penultimate hop is popping transport label, TT= L of transport label is NOT copied back to service label. When service labe= l is popped, TTL is copied NOT back to IP layer. "Pipe model" is same as short pipe but no PHP. The service label TTL treatment is more "meaningful" imo when you have a re= al tunnel at service level : the more easy example is interAS VPN option B = when you are swapping VPN labels at ASBR side or Carrier Support Carrier ca= se too, when transport label of customer is swapped to Carrier VPN label. Purely "Theorically" speaking each tunnel level (service tunnels or nested = transport tunnels) is independent in term of TTL behavior (and depends of c= onfiguration of Headend/Tailend Tunnel nodes, especially when you have nest= ed tunnels (based LDP over RSVP ...). Hope it helps, Best Regards, Stephane -----Message d'origine----- De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la part de J= ohn Smith Envoy=E9 : jeudi 2 juin 2011 00:47 =C0 : Don Heidrich (dheidric) Cc : l3vpn@ietf.org Objet : Re: Different TTLs Don, Thanks for confirming this. My doubt is specifically wrt the BGP label thats carried in the data packet= .=20 What TTL should that be set to? And is it ever modified? Note that the BGP = label is never really exposed, unless there is PHP or something. Is the TTL= of the inner label (the BGP label) set to the TTL as the IP payload? And i= f Yes, then will it *ever* be different than the IP TTL when it reaches the= other remote PE router? Thanks, John ----- Original Message ---- From: Don Heidrich (dheidric) To: John Smith Sent: Wed, 1 June, 2011 20:43:25 Subject: RE: Different TTLs John, Your assumptions are correct, one way the customer can see and trace the SP= network routers, the other the SP network appears as one hop. Re label TTL - as labels are pushed and popped at various hops the TTL is c= opied to the outer label. At the last MPLS router (or penultimate) we have = the option to copy TTL back into the IP header or not. -Don > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf=20 > Of John Smith > Sent: Wednesday, June 01, 2011 9:40 AM > To: l3vpn@ietf.org > Subject: Re: Different TTLs >=20 > Would be great if somebody can answer this! >=20 >=20 > ----- Original Message ---- > From: John Smith > To: l3vpn@ietf.org > Sent: Tue, 31 May, 2011 4:27:45 > Subject: Different TTLs >=20 > Hi, >=20 > I would like to understand the relation between the TTL carried in the=20 > BGP label >=20 > and the IP payload in the L3 VPN scenarios. As per my understanding it=20 > will always be the same as IP TTL. Is there any scenario when it will=20 > be different from the IP TTL. I understand that there are different=20 > models for carrying the transport TTL. In one model the IP TTL is=20 > copied to the transport label, which is reduced by each P hop and is=20 > finally copied back to the IP TTL field at the egress PE router. In=20 > this case the IP TTL gets decremented by as many hops as exist in the=20 > service provider network. In another, the TTL of the transport label=20 > is kept as 255 and is decremented at each hop. The IP TTL is preserved=20 > and >=20 > the customer is oblivious to the service provider topology. >=20 > Is my understanding of the two models correct? >=20 > Now, my question is what do we do about the TTL carried in the second=20 > label (the >=20 > BGP label)? Should it be kept as 255 or should we copy the IP TTL. > Whats the use >=20 > of setting any TTL there as this label is never exposed (unless=20 > someone is using >=20 > implicit null at the egress that is). >=20 > Thanks, John ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From touch@isi.edu Wed Jun 22 17:49:49 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD51D11E8071 for ; Wed, 22 Jun 2011 17:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkX7UUM-eTz9 for ; Wed, 22 Jun 2011 17:49:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCAE11E808F for ; Wed, 22 Jun 2011 17:49:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p5N0ndwV001188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2011 17:49:39 -0700 (PDT) Message-ID: <4E028DA3.3010207@isi.edu> Date: Wed, 22 Jun 2011 17:49:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: stephane.litkowski@orange-ftgroup.com Subject: Re: Different TTLs References: <917871.15418.qm@web27201.mail.ukl.yahoo.com><813783.91263.qm@web27208.mail.ukl.yahoo.com> <720565.10030.qm@web27207.mail.ukl.yahoo.com> <14592_1307094162_4DE8AC92_14592_117798_1_4FC3556A36EE3646A09DAA60429F53350675C12E@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <14592_1307094162_4DE8AC92_14592_117798_1_4FC3556A36EE3646A09DAA60429F53350675C12E@PUEXCBL0.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: John Smith , l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 00:49:50 -0000 On 6/3/2011 2:42 AM, stephane.litkowski@orange-ftgroup.com wrote: > Hi, > > Each label level is representing a specific level of tunneling. > > If you consider Uniform model, and service+transport MPLS, MPLS TTL is set IP TTL value when PE is doing encapsulation (double push). When penultimate hop is popping transport label, TTL of transport label is copied back to service label. When service label is popped, TTL is copied back to IP layer. > > If you consider "Short pipe", MPLS TTL is set to 255 when PE is doing encapsulation (double push). When penultimate hop is popping transport label, TTL of transport label is NOT copied back to service label. When service label is popped, TTL is copied NOT back to IP layer. > "Pipe model" is same as short pipe but no PHP. > > The service label TTL treatment is more "meaningful" imo when you have a real tunnel at service level : the more easy example is interAS VPN option B when you are swapping VPN labels at ASBR side or Carrier Support Carrier case too, when transport label of customer is swapped to Carrier VPN label. > > Purely "Theorically" speaking each tunnel level (service tunnels or nested transport tunnels) is independent in term of TTL behavior (and depends of configuration of Headend/Tailend Tunnel nodes, especially when you have nested tunnels (based LDP over RSVP ...). That makes sense regarding the tunnel, but the ingress/egress ought to be decrementing the TTL since they behave as RFC1812 routers if they're not strictly the source/sink of the packets entering the tunnel. Joe > Hope it helps, > > Best Regards, > > > Stephane > > -----Message d'origine----- > De : l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] De la part de John Smith > Envoyé : jeudi 2 juin 2011 00:47 > À : Don Heidrich (dheidric) > Cc : l3vpn@ietf.org > Objet : Re: Different TTLs > > Don, > > Thanks for confirming this. > > My doubt is specifically wrt the BGP label thats carried in the data packet. > What TTL should that be set to? And is it ever modified? Note that the BGP label is never really exposed, unless there is PHP or something. Is the TTL of the inner label (the BGP label) set to the TTL as the IP payload? And if Yes, then will it *ever* be different than the IP TTL when it reaches the other remote PE router? > > Thanks, John > > > ----- Original Message ---- > From: Don Heidrich (dheidric) > To: John Smith > Sent: Wed, 1 June, 2011 20:43:25 > Subject: RE: Different TTLs > > John, > > Your assumptions are correct, one way the customer can see and trace the SP network routers, the other the SP network appears as one hop. > > Re label TTL - as labels are pushed and popped at various hops the TTL is copied to the outer label. At the last MPLS router (or penultimate) we have the option to copy TTL back into the IP header or not. > > -Don > >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >> Of John Smith >> Sent: Wednesday, June 01, 2011 9:40 AM >> To: l3vpn@ietf.org >> Subject: Re: Different TTLs >> >> Would be great if somebody can answer this! >> >> >> ----- Original Message ---- >> From: John Smith >> To: l3vpn@ietf.org >> Sent: Tue, 31 May, 2011 4:27:45 >> Subject: Different TTLs >> >> Hi, >> >> I would like to understand the relation between the TTL carried in the >> BGP label >> >> and the IP payload in the L3 VPN scenarios. As per my understanding it >> will always be the same as IP TTL. Is there any scenario when it will >> be different from the IP TTL. I understand that there are different >> models for carrying the transport TTL. In one model the IP TTL is >> copied to the transport label, which is reduced by each P hop and is >> finally copied back to the IP TTL field at the egress PE router. In >> this case the IP TTL gets decremented by as many hops as exist in the >> service provider network. In another, the TTL of the transport label >> is kept as 255 and is decremented at each hop. The IP TTL is preserved >> and >> >> the customer is oblivious to the service provider topology. >> >> Is my understanding of the two models correct? >> >> Now, my question is what do we do about the TTL carried in the second >> label (the >> >> BGP label)? Should it be kept as 255 or should we copy the IP TTL. >> Whats the use >> >> of setting any TTL there as this label is never exposed (unless >> someone is using >> >> implicit null at the egress that is). >> >> Thanks, John > > ******************************************************************************** > IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de tout virus. > > IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. > Any unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > ******************************************************************************** > From internet-drafts@ietf.org Thu Jun 23 21:07:23 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77111E81A4; Thu, 23 Jun 2011 21:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmphXMYYoChu; Thu, 23 Jun 2011 21:07:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99611E808F; Thu, 23 Jun 2011 21:07:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-ibgp-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110624040723.12552.65455.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2011 21:07:23 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 04:07:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : Internal BGP as Provider/Customer Edge Protocol for BGP/= MPLS IP Virtual Private Networks (VPNs) Author(s) : Pedro Marques Robert Raszuk Keyur Patel Kenji Kumaki Tomohiro Yamagata Filename : draft-ietf-l3vpn-ibgp-08.txt Pages : 19 Date : 2011-06-23 This document defines protocol extensions and procedures for BGP Provider/Customer edge router iteration in BGP/MPLS IP VPN networks. These have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-08.txt