From nobody Mon Jun 2 12:36:58 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526D01A03FF for ; Mon, 2 Jun 2014 12:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17CNEYCavyS9 for ; Mon, 2 Jun 2014 12:36:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874A21A0369 for ; Mon, 2 Jun 2014 12:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3497; q=dns/txt; s=iport; t=1401737809; x=1402947409; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=epBwNKkGTvkevNq0FKYnrK0EiDPHriOx74v/DXx4H60=; b=ZjRjNjhH8RSL9v7l8DJ5Dg51j0zigWf1AZnMISgjAqYxpIbI9uHDX8xe O9FeDNET/Ao8ZYWeMdaCgRGAYJDKKgkPxju7N3DqBTfGtWvOxI8qZfTne gfejOGp85BnmTGtDq/FCnSzTKTFeYr5cjMTOYGeXsXEpWXeT8DIJHmczY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAEPRjFOtJV2c/2dsb2JhbAA/GoMHUlUDwlkBgRUWdIIlAQEBAwEdXAULAgEIEgYuMhcOAgQOBYg6CEPPARMEjh8zB4MrgRUEiWuMEIQFky2BeIFAbIFD X-IronPort-AV: E=Sophos;i="4.98,958,1392163200"; d="scan'208";a="49463947" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 02 Jun 2014 19:36:48 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s52Jam3G024021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 19:36:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.85]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 14:36:48 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPSq40P8CAt6t4pEKHvEzjBJGgzZr3VmaAgF4dNgCABMzHAIAEsZwA Date: Mon, 2 Jun 2014 19:36:47 +0000 Message-ID: References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201403281736.s2SHawV72952@magenta.juniper.net> <20140328212333.GE30644@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.171.192] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <570A4ACB3998E848A1894D2055FBC833@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/rsNYdx4NmRY1DG3gz0CPKtDKTiI Cc: Yakov Rekhter , "Eric Vyncke \(evyncke\)" , "" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:36:56 -0000 On May 30, 2014, at 9:54 PM, Hannes Gredler wrote: > eric, >=20 > > if *just* loose source routing is required, then the same can get achieve= d using > nested IP tunnels. no need for new architecture, no need for new signalin= g protocol extensions, > perhaps some re-spin of forwarding hardware in order to push the large tu= nnel strings. > . maybe but I don't see the advantage while SRH gives you way more=20 capabilities that, at some point, may be requested as well (TE,=20 LFA, EPE, ...). > point is that you can't get away with loose source routing semantics for = supporting > all the SR use-cases. thus the current 6man draft needs rework in order > to be somewhat feature congruent to the mpls-dataplane, which stefano > has agreed to post _soon_. that is correct. According to the comments received on version -00=20 (among which, yours) a new version is going to be released as soon=20 as the co-authors completed the internal review. If it doesn't go fast enough for you, well, you'll have to live with=20 that feeling. > i hope it does not take another 12 months > (e.g. like the last time when we have asked for the data ipv6-sr plane sp= ecification > presented at mplswc2013 - actual publication data was feb 2014 ...) - Indeed, SR-IPv6 was initially presented at mplswc2013, then it=20 triggered interest and collaboration from many parties. Note that=20 we met during a couple of hours in Paris at that time and we gave=20 you all the details of what we had in mind, including the ipv6=20 part.=20 Then, at some point in the cycle, we published a draft describing=20 what the authors worked out in terms of architecture and SRH details.=20 I don't think I have to come with a justification about the amount=20 of time it took. Anyway, in the mean time, implementation work from multiple parties=20 started (for both mpls and v6 dataplanes). Now that we have multiple=20 implementations, we are working on interoperability and we will,=20 probably, again update some of the details but don't take this as a=20 commitment from my side to publish anything in a delay that suits=20 your time perception.=20 s. > tx, >=20 > /hannes >=20 > On May 27, 2014, at 8:36 PM, Eric Vyncke (evyncke) wrote: >=20 >> Late reply to Hannes point: >>=20 >> On 28/03/14 22:23, "Hannes Gredler" wrote: >>>=20 >>> the real question is what percentage of public Internet routers >>>=20 >>> 1) does have MPLS hardware forwarding support >>> 2) does have IPv6-SR hardware forwarding support. >>>=20 >>> And >>=20 >> Regarding the IPv6-SR compatibility, as SRH is basically 'loose source >> routing', it only requires: >> - SRH processing by all SR-enabled router whose segment id is in the SRH= , >> typically some PE routers. Those will need to be modified indeed but tho= se >> will be minority >> - SRH forwarding (i.e. Not parsing or acting upon the SRH) for all >> remaining routers. Those will be the majority >>=20 >> The latter is currently OK, I wrote a small script >> https://www.vyncke.org/sr.php which basically sends a dummy SRH to your >> browser (requirement is that your browser/clients supports IPv6) and aft= er >> a dozen of tests, all were successful. While this is not a mathematical >> proof, this is good enough from my engineer's point of view >>=20 >> Hope this helps >>=20 >> -=E9ric >>=20 >=20 From nobody Thu Jun 5 02:46:55 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116D71A0132; Thu, 5 Jun 2014 02:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXD2jgweEOBK; Thu, 5 Jun 2014 02:46:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D72C1A041D; Thu, 5 Jun 2014 02:46:51 -0700 (PDT) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (10.255.150.37) by DM2PR05MB399.namprd05.prod.outlook.com (10.141.102.14) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 09:46:42 +0000 Received: from [172.29.65.217] (193.110.55.18) by pod51010.outlook.com (10.255.150.37) with Microsoft SMTP Server (TLS) id 14.16.459.0; Thu, 5 Jun 2014 09:46:41 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Thu, 5 Jun 2014 11:46:39 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: Xuxiaohu X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.55.18] X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(199002)(189002)(51704005)(377454003)(55784002)(101416001)(77096999)(57306001)(86362001)(64706001)(80022001)(76482001)(74502001)(50466002)(93916002)(79102001)(36756003)(92566001)(92726001)(74662001)(15202345003)(77156001)(20776003)(21056001)(87936001)(99396002)(50986999)(76176999)(33656002)(85852003)(83072002)(104166001)(4396001)(31966008)(46102001)(23756003)(62966002)(50226001)(82746002)(89996001)(83322001)(19580405001)(81542001)(19580395003)(47776003)(66066001)(83716003)(15975445006)(87286001)(102836001)(81342001)(77982001)(88136002)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB399; H:CH1PRD0510HT002.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/GlI-2_ugNakVpVWOJezqN6xKVWg Cc: "stephane.litkowski@orange.com>" , isis-chairs@tools.ietf.org, "" , draft-xu-isis-mpls-elc@tools.ietf.org, "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:46:54 -0000 i'm discomfortable with the *granularity* of the cap-advertisement: rather than saying: "i can crawl as deep as you like on any of my interfaces" i'd like to announce: "i can crawl for EL up to labels deep on interface XYZ" /hannes On Jun 3, 2014, at 2:17 PM, = wrote: > Hi, >=20 > IMHO, before defining the capability, I would be more interrested on = seeing some progress on a solution for EL over SPRING. A draft exists = with multiple options, maybe we should wait for one option to have = consensus before worrying about ELC encoding (quite easy part of the EL = for SPRING). >=20 >=20 > Stephane >=20 > -----Message d'origine----- > De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de Xuxiaohu > Envoy=E9 : samedi 31 mai 2014 10:05 > =C0 : isis-chairs@tools.ietf.org > Cc : draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org > Objet : [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 >=20 > Hi WG co-chairs, >=20 > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) = describes how to advertise the MPLS Entropy Label Capability (ELC) using = IS-IS in SPRING networks. Since = (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00)= has been adopted as a WG draft, as co-authors of = draft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption = for this draft as well. >=20 > Best regards, > Xiaohu (on behalf of all-authors) =20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Thu Jun 5 06:34:27 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDFA1A014F; Thu, 5 Jun 2014 06:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHasCUUgGchI; Thu, 5 Jun 2014 06:34:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F43E1A012D; Thu, 5 Jun 2014 06:34:13 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D9DAA3243FC; Thu, 5 Jun 2014 15:34:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AED5F4C06B; Thu, 5 Jun 2014 15:34:05 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.19]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 15:34:05 +0200 From: To: Hannes Gredler , Xuxiaohu Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAKATQMAAWzLIgAAMDyVg Date: Thu, 5 Jun 2014 13:34:04 +0000 Message-ID: <21360_1401975245_539071CD_21360_4036_1_9E32478DFA9976438E7A22F69B08FF9201DD93@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.5.105118 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/7XrOLSM5cFjii0zseB5oAI7BiAc Cc: "isis-chairs@tools.ietf.org" , "" , "draft-xu-isis-mpls-elc@tools.ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:34:21 -0000 Hi Hannes, I agree with you but if draft-kini-mpls-spring-entropy-label evolve to the = option where entropy label is always behind top label, there is no need to = encode such granularity. That's why I think it's too early to progress the capability document. Thoughts ? Stephane -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net]=20 Sent: Thursday, June 05, 2014 11:47 To: Xuxiaohu Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; isis= -wg@ietf.org list; LITKOWSKI Stephane SCE/IBNF; Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 i'm discomfortable with the *granularity* of the cap-advertisement: rather than saying: "i can crawl as deep as you like on any of my interfaces" i'd like to announce: "i can crawl for EL up to labels deep on interface XYZ" /hannes On Jun 3, 2014, at 2:17 PM, wrote: > Hi, >=20 > IMHO, before defining the capability, I would be more interrested on seei= ng some progress on a solution for EL over SPRING. A draft exists with mult= iple options, maybe we should wait for one option to have consensus before = worrying about ELC encoding (quite easy part of the EL for SPRING). >=20 >=20 > Stephane >=20 > -----Message d'origine----- > De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de Xuxiaohu=20 > Envoy=E9 : samedi 31 mai 2014 10:05 =C0 : isis-chairs@tools.ietf.org Cc := =20 > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet :=20 > [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 >=20 > Hi WG co-chairs, >=20 > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) describ= es how to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in = SPRING networks. Since (http://tools.ietf.org/html/draft-ietf-isis-segment-= routing-extensions-00) has been adopted as a WG draft, as co-authors of dra= ft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption for this= draft as well. >=20 > Best regards, > Xiaohu (on behalf of all-authors) >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jun 5 11:51:56 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D571A0254 for ; Thu, 5 Jun 2014 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgseCV3TljBB for ; Thu, 5 Jun 2014 11:51:52 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0E21A0163 for ; Thu, 5 Jun 2014 11:51:52 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so1362163wes.23 for ; Thu, 05 Jun 2014 11:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=KM/L2UlGbpaXtFvxCN0uLccUKbKA8bfV+skNaXJQhd8=; b=RMfKVB/onEeFX1BKtL/0Yhz6MFWyaknoZVmm5HSnQQGRZqZY4mF2xBEEytlhaNH0ox k56DP8J8NHIye+VEoJ2j0PybFHfZ5FWEuNCaC9+xd+i/TwRZU8dOKbhPZu36CYeYUkxQ okkfJ7jtMkWJVRrAbwAvVMviVOIXLvJq1/1Il7U6wLjC/nUsfrrl+5eDffruAjPlshG0 K9uaMV0qutMV7z1G0Lwe+cx0wKOkPjo+hygrcFHpejl/PuK3pAgrGiPX2pZUvk4sXD8F IOwVHcdTl/GwG/EgybqYti58LkmRra25cRu7V1oe0pBke5FnWJ51uUJdnbmgkDwIqU55 Oa6g== MIME-Version: 1.0 X-Received: by 10.180.97.131 with SMTP id ea3mr18206124wib.35.1401994304459; Thu, 05 Jun 2014 11:51:44 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.182.67 with HTTP; Thu, 5 Jun 2014 11:51:44 -0700 (PDT) In-Reply-To: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> Date: Thu, 5 Jun 2014 11:51:44 -0700 X-Google-Sender-Auth: 82Nhu4SZmonCMXUbesbBHfNoXhE Message-ID: From: Anoop Ghanwani To: "spring@ietf.org" Content-Type: multipart/alternative; boundary=f46d04426dec7e98cc04fb1b3c88 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/vvnFggVG3jGTeKmyNGBKnavCd94 Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:51:54 -0000 --f46d04426dec7e98cc04fb1b3c88 Content-Type: text/plain; charset=ISO-8859-1 I have a question about this draft. In section 2, it has the following statement: >>> >From a SPRING viewpoint, we would like to highlight the following requirement: the two configured paths T1 and T2 MUST NOT benefit from local protection. >>> But there is no such statement in subsequent sections. So suppose I have a data packet using SPRING to use path A - B - C. If B is down, would such packets be discarded or would there be an attempt to get it to C if one of the other methods for repair is configured? Anoop On Tue, May 13, 2014 at 9:35 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Source Packet Routing in Networking > Working Group of the IETF. > > Title : Use-cases for Resiliency in SPRING > Authors : Pierre Francois > Clarence Filsfils > Bruno Decraene > Rob Shakir > Filename : draft-ietf-spring-resiliency-use-cases-00.txt > Pages : 8 > Date : 2014-05-12 > > Abstract: > This document describes the use cases for resiliency in SPRING > networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --f46d04426dec7e98cc04fb1b3c88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have a question about this draft.

In = section 2, it has the following statement:
>>>
>From a SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local protection.
>>>

But there is no such statement in subsequent sectio= ns.

So= suppose I have a data packet using SPRING to use path A - B - C. =A0If B i= s down, would such packets be discarded or would there be an attempt to get= it to C if one of the other methods for repair is configured?

Anoop
On Tue, May 13, 2014 at 9:35 AM, <int= ernet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Source Packet Routing in Networking Wor= king Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Use-cases for Resiliency in SPR= ING
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Pierre Francois
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clarence Filsfils
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bruno Decraene
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rob Shakir
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-spring-resiliency-use-= cases-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-05-12

Abstract:
=A0 =A0This document describes the use cases for resiliency in SPRING
=A0 =A0networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spr= ing-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resili= ency-use-cases-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring

--f46d04426dec7e98cc04fb1b3c88-- From nobody Thu Jun 5 19:29:18 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46ED11A03BD; Thu, 5 Jun 2014 19:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSBCoyd8m6cH; Thu, 5 Jun 2014 19:29:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30A21A03BB; Thu, 5 Jun 2014 19:29:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHW83388; Fri, 06 Jun 2014 02:29:07 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 03:28:13 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 03:29:04 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 10:28:57 +0800 From: Xuxiaohu To: Hannes Gredler Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAKATQMAATqAigAARemRw Date: Fri, 6 Jun 2014 02:28:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EB7D@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/RUth4ZNVL6G0MemWXrvyxBXLIYk Cc: "mpls@ietf.org" , "isis-chairs@tools.ietf.org" , "draft-xu-isis-mpls-elc@tools.ietf.org" , "" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 02:29:17 -0000 Hi Hannes, It seems that you are not talking about the particular ELC concept as defin= ed in RFC6790 (i..e, the capability of recognizing the ELI and popping that= ELI and the following EL). Instead, it seems that you are talking about so= mething else related to the capability of accessing the maximum label stack= depth. As for the granularity of the ELC advertisement (i.e., per-node basis or pe= r-interface-board basis), it has been discussed before. Although the ELC is= interface-board related, since it's almost impossible to determine at whic= h interface a packet destined for one of the router's addresses would arriv= e (e.g., a MPLS packet with the top label being a node segment ID of a give= n LSR), the feasible way of advertising the ELC is: the egress LSR SHOULD n= ot advertise its ELC unless all of its interface-boards have the ELC. By th= e way, this is exactly the same way that can be supported by RFC6790, IMHO. Best regards, Xiaohu=20 > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredl= er > Sent: Thursday, June 05, 2014 5:47 PM > To: Xuxiaohu > Cc: isis-chairs@tools.ietf.org; ; > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org list > Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-= 00 >=20 > >=20 > i'm discomfortable with the *granularity* of the cap-advertisement: >=20 > rather than saying: >=20 > "i can crawl as deep as you like on any of my interfaces" >=20 > i'd like to announce: >=20 > "i can crawl for EL up to labels deep on interface XYZ" >=20 >=20 > /hannes >=20 > On Jun 3, 2014, at 2:17 PM, > wrote: >=20 > > Hi, > > > > IMHO, before defining the capability, I would be more interrested on se= eing > some progress on a solution for EL over SPRING. A draft exists with multi= ple > options, maybe we should wait for one option to have consensus before > worrying about ELC encoding (quite easy part of the EL for SPRING). > > > > > > Stephane > > > > -----Message d'origine----- > > De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de Xuxiaohu > > Envoy=E9 : samedi 31 mai 2014 10:05 =C0 : isis-chairs@tools.ietf.org Cc= : > > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet : > > [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 > > > > Hi WG co-chairs, > > > > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) descr= ibes how > to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRIN= G > networks. Since > (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00= ) has > been adopted as a WG draft, as co-authors of draft-xu-isis-mpls-elc-00, w= e hope > you could consider the WG adoption for this draft as well. > > > > Best regards, > > Xiaohu (on behalf of all-authors) > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > _____________________________________________________________ > _________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Oran= ge > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Thu Jun 5 19:37:26 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320C71A03D1; Thu, 5 Jun 2014 19:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8cH1m2zFdst; Thu, 5 Jun 2014 19:37:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366F41A03C6; Thu, 5 Jun 2014 19:37:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHW83856; Fri, 06 Jun 2014 02:37:10 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 03:36:18 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 03:37:09 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 10:37:06 +0800 From: Xuxiaohu To: "stephane.litkowski@orange.com" , "Hannes Gredler" Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAKATQMAATqAigAAH8UMAACvfrhA= Date: Fri, 6 Jun 2014 02:37:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EBA2@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> <21360_1401975245_539071CD_21360_4036_1_9E32478DFA9976438E7A22F69B08FF9201DD93@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <21360_1401975245_539071CD_21360_4036_1_9E32478DFA9976438E7A22F69B08FF9201DD93@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/QLmf-Ruk38Dyv_F2Ew2ev52CK6Y Cc: "isis-chairs@tools.ietf.org" , "" , "draft-xu-isis-mpls-elc@tools.ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 02:37:21 -0000 > -----Original Message----- > From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com= ] > Sent: Thursday, June 05, 2014 9:34 PM > To: Hannes Gredler; Xuxiaohu > Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; > isis-wg@ietf.org list; > Subject: RE: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-= 00 >=20 > Hi Hannes, >=20 > I agree with you but if draft-kini-mpls-spring-entropy-label evolve to th= e option > where entropy label is always behind top label, there is no need to encod= e such > granularity. > That's why I think it's too early to progress the capability document. Whether or not delay the adoption of the ELC advertisement doc, I have to p= oint out the fact that the ELC advertisement DOESN'T impact the EL insertio= n solution, and vice versa. If you disagree, please give a concrete example= . Best regards, Xiaohu > Thoughts ? >=20 > Stephane >=20 > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Thursday, June 05, 2014 11:47 > To: Xuxiaohu > Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; > isis-wg@ietf.org list; LITKOWSKI Stephane SCE/IBNF; > Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-= 00 >=20 > >=20 > i'm discomfortable with the *granularity* of the cap-advertisement: >=20 > rather than saying: >=20 > "i can crawl as deep as you like on any of my interfaces" >=20 > i'd like to announce: >=20 > "i can crawl for EL up to labels deep on interface XYZ" >=20 >=20 > /hannes >=20 > On Jun 3, 2014, at 2:17 PM, > wrote: >=20 > > Hi, > > > > IMHO, before defining the capability, I would be more interrested on se= eing > some progress on a solution for EL over SPRING. A draft exists with multi= ple > options, maybe we should wait for one option to have consensus before > worrying about ELC encoding (quite easy part of the EL for SPRING). > > > > > > Stephane > > > > -----Message d'origine----- > > De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de Xuxiaohu > > Envoy=E9 : samedi 31 mai 2014 10:05 =C0 : isis-chairs@tools.ietf.org Cc= : > > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet : > > [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 > > > > Hi WG co-chairs, > > > > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) descr= ibes how > to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRIN= G > networks. Since > (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00= ) has > been adopted as a WG draft, as co-authors of draft-xu-isis-mpls-elc-00, w= e hope > you could consider the WG adoption for this draft as well. > > > > Best regards, > > Xiaohu (on behalf of all-authors) > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > _____________________________________________________________ > _________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Oran= ge > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg >=20 >=20 > _____________________________________________________________ > ____________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute respo= nsabilite > si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Thu Jun 5 20:53:03 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB101A0149; Thu, 5 Jun 2014 20:53:00 -0700 (PDT) X-Quarantine-ID: <4HSvqbrTd2AK> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...@OPEXCLILM34.corporate.adroot.infra.ftgroup>\n X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HSvqbrTd2AK; Thu, 5 Jun 2014 20:52:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815531A01C5; Thu, 5 Jun 2014 20:52:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX66692; Fri, 06 Jun 2014 03:52:50 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 04:51:57 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 04:52:49 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 11:52:37 +0800 From: Xuxiaohu To: Xuxiaohu , "stephane.litkowski@orange.com" , Hannes Gredler Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAKATQMAATqAigAAH8UMAACvfrhAAAlw+wA== Date: Fri, 6 Jun 2014 03:52:37 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EBEB@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> <21360_1401975245_539071CD_21360_4036_1_9E32478DFA9976438E7A22F69B08FF9201DD93@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/g98tX_gowD29B_QxfGC66xTJbWg Cc: "isis-chairs@tools.ietf.org" , "" , "draft-xu-isis-mpls-elc@tools.ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 03:53:00 -0000 Stephane , Oh, I finally realized the reason why we have different opinions on whether= the ELC advertisement is orthogonal to the EL insertion solution. That's b= ecause we have different understanding of the concept of the "ELC". My unde= rstanding of the "ELC" is in accordance with the particular ELC concept as = defined in RFC6790 (i.e., the capability of recognizing the ELI and popping= ELI and EL, in addition, this is the capability of the EGRESS LSR). Your u= nderstanding of the "ELC" looks like a mix of the particular ELC concept as= defined in RFC6790 and something else (e.g., the capability of accessing t= he max label stack deepth) Best regards, Xiaohu > -----Original Message----- > From: Xuxiaohu > Sent: Friday, June 06, 2014 10:37 AM > To: 'stephane.litkowski@orange.com'; Hannes Gredler > Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; > isis-wg@ietf.org list; > Subject: RE: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-= 00 >=20 >=20 >=20 > > -----Original Message----- > > From: stephane.litkowski@orange.com > > [mailto:stephane.litkowski@orange.com] > > Sent: Thursday, June 05, 2014 9:34 PM > > To: Hannes Gredler; Xuxiaohu > > Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; > > isis-wg@ietf.org list; > > Subject: RE: [Isis-wg] Request for WG adoption of > > draft-xu-isis-mpls-elc-00 > > > > Hi Hannes, > > > > I agree with you but if draft-kini-mpls-spring-entropy-label evolve to > > the option where entropy label is always behind top label, there is no > > need to encode such granularity. > > That's why I think it's too early to progress the capability document. >=20 > Whether or not delay the adoption of the ELC advertisement doc, I have to= point > out the fact that the ELC advertisement DOESN'T impact the EL insertion s= olution, > and vice versa. If you disagree, please give a concrete example. >=20 > Best regards, > Xiaohu >=20 > > Thoughts ? > > > > Stephane > > > > -----Original Message----- > > From: Hannes Gredler [mailto:hannes@juniper.net] > > Sent: Thursday, June 05, 2014 11:47 > > To: Xuxiaohu > > Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; > > isis-wg@ietf.org list; LITKOWSKI Stephane SCE/IBNF; > > Subject: Re: [Isis-wg] Request for WG adoption of > > draft-xu-isis-mpls-elc-00 > > > > > > > > i'm discomfortable with the *granularity* of the cap-advertisement: > > > > rather than saying: > > > > "i can crawl as deep as you like on any of my interfaces" > > > > i'd like to announce: > > > > "i can crawl for EL up to labels deep on interface XYZ" > > > > > > /hannes > > > > On Jun 3, 2014, at 2:17 PM, > > wrote: > > > > > Hi, > > > > > > IMHO, before defining the capability, I would be more interrested on > > > seeing > > some progress on a solution for EL over SPRING. A draft exists with > > multiple options, maybe we should wait for one option to have > > consensus before worrying about ELC encoding (quite easy part of the EL= for > SPRING). > > > > > > > > > Stephane > > > > > > -----Message d'origine----- > > > De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de > > > Xuxiaohu Envoy=E9 : samedi 31 mai 2014 10:05 =C0 : isis-chairs@tools.= ietf.org > Cc : > > > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet : > > > [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 > > > > > > Hi WG co-chairs, > > > > > > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) > > > describes how > > to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in > > SPRING networks. Since > > (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions > > -00) has been adopted as a WG draft, as co-authors of > > draft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption f= or > this draft as well. > > > > > > Best regards, > > > Xiaohu (on behalf of all-authors) > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > Isis-wg@ietf.org > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > _____________________________________________________________ > > _________ > > > ___________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > detruire ainsi que les pieces > > jointes. Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme= ou > falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > > privileged information that may be protected by law; they should not > > > be > > distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender > > > and delete this > > message and its attachments. > > > As emails may be altered, Orange is not liable for messages that > > > have been > > modified, changed or falsified. > > > Thank you. > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > Isis-wg@ietf.org > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > > > _____________________________________________________________ > > > ____________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > > que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. From nobody Fri Jun 6 00:14:55 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85BE1A010A; Fri, 6 Jun 2014 00:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVvQsuKAkU6n; Fri, 6 Jun 2014 00:14:50 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8451A0047; Fri, 6 Jun 2014 00:14:49 -0700 (PDT) Received: from CH1PRD0510HT005.namprd05.prod.outlook.com (10.255.150.40) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 6 Jun 2014 07:14:35 +0000 Received: from [172.29.65.217] (193.110.55.18) by pod51010.outlook.com (10.255.150.40) with Microsoft SMTP Server (TLS) id 14.16.459.0; Fri, 6 Jun 2014 07:14:34 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <21360_1401975245_539071CD_21360_4036_1_9E32478DFA9976438E7A22F69B08FF9201DD93@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Fri, 6 Jun 2014 09:14:31 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> <21360_1401975245_539071CD_21360_4036_1_9E32478DFA9976438E7A22F69B08FF9201DD93@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.55.18] X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 023495660C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(979002)(6009001)(428001)(55784002)(51704005)(13464003)(199002)(189002)(377454003)(24454002)(16614003)(92566001)(81542001)(92726001)(93916002)(31966008)(4396001)(76482001)(23756003)(101416001)(66066001)(80022001)(79102001)(74502001)(104166001)(86362001)(74662001)(47776003)(20776003)(64706001)(77982001)(57306001)(21056001)(50226001)(36756003)(50466002)(99396002)(77156001)(62966002)(89996001)(93886002)(85852003)(83072002)(81342001)(83716003)(87286001)(102836001)(19580395003)(19580405001)(83322001)(33656002)(88136002)(82746002)(87936001)(46102001)(50986999)(77096999)(15975445006)(15202345003)(76176999)(104396001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB715; H:CH1PRD0510HT005.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Zep0QlXPJfR6qmREmexE6m2K51Y Cc: Xuxiaohu , "" , "draft-xu-isis-mpls-elc@tools.ietf.org" , "isis-chairs@tools.ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:14:53 -0000 valid point - i am not terribly happy with the EL behind the top label = as it may require new data plane capabilities (you need to retain the EL label while the SR stack gets POPed off). - not sure if all existing MPLS HW does support that. /hannes=20 On Jun 5, 2014, at 3:34 PM, wrote: > Hi Hannes, >=20 > I agree with you but if draft-kini-mpls-spring-entropy-label evolve to = the option where entropy label is always behind top label, there is no = need to encode such granularity. > That's why I think it's too early to progress the capability document. >=20 > Thoughts ? >=20 > Stephane >=20 > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net]=20 > Sent: Thursday, June 05, 2014 11:47 > To: Xuxiaohu > Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; = isis-wg@ietf.org list; LITKOWSKI Stephane SCE/IBNF; > Subject: Re: [Isis-wg] Request for WG adoption of = draft-xu-isis-mpls-elc-00 >=20 > >=20 > i'm discomfortable with the *granularity* of the cap-advertisement: >=20 > rather than saying: >=20 > "i can crawl as deep as you like on any of my interfaces" >=20 > i'd like to announce: >=20 > "i can crawl for EL up to labels deep on interface XYZ" >=20 >=20 > /hannes >=20 > On Jun 3, 2014, at 2:17 PM, = wrote: >=20 >> Hi, >>=20 >> IMHO, before defining the capability, I would be more interrested on = seeing some progress on a solution for EL over SPRING. A draft exists = with multiple options, maybe we should wait for one option to have = consensus before worrying about ELC encoding (quite easy part of the EL = for SPRING). >>=20 >>=20 >> Stephane >>=20 >> -----Message d'origine----- >> De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de Xuxiaohu=20= >> Envoy=E9 : samedi 31 mai 2014 10:05 =C0 : isis-chairs@tools.ietf.org = Cc :=20 >> draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet :=20 >> [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 >>=20 >> Hi WG co-chairs, >>=20 >> This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) = describes how to advertise the MPLS Entropy Label Capability (ELC) using = IS-IS in SPRING networks. Since = (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00)= has been adopted as a WG draft, as co-authors of = draft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption = for this draft as well. >>=20 >> Best regards, >> Xiaohu (on behalf of all-authors) >>=20 >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Fri Jun 6 00:38:17 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410001A03D8; Fri, 6 Jun 2014 00:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOueRuispIt5; Fri, 6 Jun 2014 00:38:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34B11A0376; Fri, 6 Jun 2014 00:38:12 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id B54961903A1; Fri, 6 Jun 2014 09:38:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 92B7EC8056; Fri, 6 Jun 2014 09:38:04 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.19]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 09:38:04 +0200 From: To: Hannes Gredler Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAKATQMAAWzLIgAAxLZrTAACtKBA= Date: Fri, 6 Jun 2014 07:38:04 +0000 Message-ID: <1356_1402040284_53916FDC_1356_5092_1_9E32478DFA9976438E7A22F69B08FF9201DFAF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> <21360_1401975245_539071CD_21360_4036_1_9E32478DFA9976438E7A22F69B08FF9201DD93@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.5.221820 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ALakw32G0FIhhtdhuCan3JETKzA Cc: Xuxiaohu , "" , "draft-xu-isis-mpls-elc@tools.ietf.org" , "isis-chairs@tools.ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:38:15 -0000 You are right, I think EL processing in SPRING is mainly an implementor dis= cussion about what is possible to do, what's the impact on legacy HWs ... Some HW may also never be able to look at EL if it's 7 or 8 labels after th= e top one ... and FAT PW solution (FAT label at bottom of stack) may not wo= rk anymore.=20 -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net]=20 Sent: Friday, June 06, 2014 09:15 To: LITKOWSKI Stephane SCE/IBNF Cc: Xuxiaohu; isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf= .org; isis-wg@ietf.org list; Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 valid point - i am not terribly happy with the EL behind the top label as i= t may require new data plane capabilities (you need to retain the EL label = while the SR stack gets POPed off). - not sure if all existing MPLS HW does= support that. /hannes=20 On Jun 5, 2014, at 3:34 PM, wrote: > Hi Hannes, >=20 > I agree with you but if draft-kini-mpls-spring-entropy-label evolve to th= e option where entropy label is always behind top label, there is no need t= o encode such granularity. > That's why I think it's too early to progress the capability document. >=20 > Thoughts ? >=20 > Stephane >=20 > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Thursday, June 05, 2014 11:47 > To: Xuxiaohu > Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org;=20 > isis-wg@ietf.org list; LITKOWSKI Stephane SCE/IBNF; > Subject: Re: [Isis-wg] Request for WG adoption of=20 > draft-xu-isis-mpls-elc-00 >=20 > >=20 > i'm discomfortable with the *granularity* of the cap-advertisement: >=20 > rather than saying: >=20 > "i can crawl as deep as you like on any of my interfaces" >=20 > i'd like to announce: >=20 > "i can crawl for EL up to labels deep on interface XYZ" >=20 >=20 > /hannes >=20 > On Jun 3, 2014, at 2:17 PM, wrote: >=20 >> Hi, >>=20 >> IMHO, before defining the capability, I would be more interrested on see= ing some progress on a solution for EL over SPRING. A draft exists with mul= tiple options, maybe we should wait for one option to have consensus before= worrying about ELC encoding (quite easy part of the EL for SPRING). >>=20 >>=20 >> Stephane >>=20 >> -----Message d'origine----- >> De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de Xuxiaohu=20 >> Envoy=E9 : samedi 31 mai 2014 10:05 =C0 : isis-chairs@tools.ietf.org Cc : >> draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet :=20 >> [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 >>=20 >> Hi WG co-chairs, >>=20 >> This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) descri= bes how to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in= SPRING networks. Since (http://tools.ietf.org/html/draft-ietf-isis-segment= -routing-extensions-00) has been adopted as a WG draft, as co-authors of dr= aft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption for thi= s draft as well. >>=20 >> Best regards, >> Xiaohu (on behalf of all-authors) >>=20 >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jun 6 02:18:12 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51311A0407 for ; Fri, 6 Jun 2014 02:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olbDyv2i1fHS for ; Fri, 6 Jun 2014 02:18:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE7C1A02EE for ; Fri, 6 Jun 2014 02:18:08 -0700 (PDT) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (10.255.84.39) by BL2PR05MB180.namprd05.prod.outlook.com (10.242.198.20) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 6 Jun 2014 09:18:01 +0000 Received: from juniper.net (193.110.55.18) by pod51010.outlook.com (10.255.84.39) with Microsoft SMTP Server (TLS) id 14.16.459.0; Fri, 6 Jun 2014 09:17:59 +0000 Date: Fri, 6 Jun 2014 11:17:54 +0200 From: Hannes Gredler To: "Stefano Previdi (sprevidi)" Message-ID: <20140606091754.GB12354@juniper.net> References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201403281736.s2SHawV72952@magenta.juniper.net> <20140328212333.GE30644@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.55.18] X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 023495660C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(52314003)(24454002)(189002)(199002)(97756001)(87936001)(46102001)(81342001)(71816001)(99396002)(21056001)(92726001)(92566001)(83072002)(50466002)(54356999)(50986999)(76176999)(86362001)(81542001)(79102001)(31966008)(4396001)(74662001)(74502001)(36756003)(93886002)(33656002)(46406003)(101416001)(23726002)(83322001)(66066001)(76482001)(80022001)(85852003)(77982001)(47776003)(64706001)(102836001)(20776003)(83506001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB180; H:BY2PRD0510HT004.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/f_lH3vm1GwO3i1nFo3GYqT_1EV8 Cc: Yakov Rekhter , "Eric Vyncke \(evyncke\)" , "" , "John G. Scudder" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:18:11 -0000 stefano, et al, my read of SR and IPv6-SR in the past year is: 1. that in 2013 you have started out with a *unified* control-plane based on stacked-tunnels technology which supports more than one data-plane. 2. because it supports 'more than' dataplane and there is a high congruency between dataplane forwarding semantics you need an overarching, common 'architecture' with new terminology etc. now lets have a closer look after more than one-year of 'SR-promised-land': 1. There is little to no SP traction on IPv6-SR. those SPs who have voiced support in all reality can be served well with nested IP tunnels based on exisiting protocols (GRE, IPIP, L2TPv3 ) 2. For certain usecases (e.g. protection, OAM, controller-based TE, etc) there is SP traction in SR-over-MPLS. 3. There is little to no congruency in terms of forwarding-semantics between the IPv6-SR dataplane and the MPLS data-plane. a) MPLS forwarding = loose and strict forwarding based on local assigned tags b) IPv6-SR forwarding = best-matching prefix forwarding based on global assigned adresses 4. the cost of adding explicit routing forwarding capabilities to IPv6 forwarding hardware is now visible (and guess what - its expensive to implement on high speed (100GBIT/s lookup engines - (parsing IPv6-extensions headers does require a lot of memory references) 5. IOW the need to support for 'more-than-one dataplane' has just shrunk down to 'one dataplane' of practical relevance (which is MPLS). 6. for *one* practical dataplane we do not need new architecture, nor new terminology. all what is required is some further clarification to rfc3031, which 'draft-gredler-spring-mpls' really is all about. what really irritates me is your repeated delay tactics around publication of 'IPv6-SR' in sufficient details, such that one can see the clear need for a *common* architecture. my trust that this will happen has gotten down to almost zero. before asking the WG to adopt a common SR architecture and terminology i'd rather ask you to *proof* the need for it. right now there is *zero* evidence on the table that we need a 'common, dataplane neutral SR architecture' at all, for supporting the practical relevant use-cases. /hannes On Mon, Jun 02, 2014 at 07:36:47PM +0000, Stefano Previdi (sprevidi) wrote: [ ... ] | > i hope it does not take another 12 months | > (e.g. like the last time when we have asked for the data ipv6-sr plane specification | > presented at mplswc2013 - actual publication data was feb 2014 ...) - | | | Indeed, SR-IPv6 was initially presented at mplswc2013, then it | triggered interest and collaboration from many parties. Note that | we met during a couple of hours in Paris at that time and we gave | you all the details of what we had in mind, including the ipv6 | part. | | Then, at some point in the cycle, we published a draft describing | what the authors worked out in terms of architecture and SRH details. | I don't think I have to come with a justification about the amount | of time it took. | | Anyway, in the mean time, implementation work from multiple parties | started (for both mpls and v6 dataplanes). Now that we have multiple | implementations, we are working on interoperability and we will, | probably, again update some of the details but don't take this as a | commitment from my side to publish anything in a delay that suits | your time perception. | | | s. From nobody Fri Jun 6 02:32:16 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA3C1A0409 for ; Fri, 6 Jun 2014 02:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wrPTo0UzHXX for ; Fri, 6 Jun 2014 02:32:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC96E1A0109 for ; Fri, 6 Jun 2014 02:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5431; q=dns/txt; s=iport; t=1402047083; x=1403256683; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EujxqMJ9ZZhWrGdasvsSeMsa/aZj7kdYhVA6Zj3UFD8=; b=dw6XgY6aMNeZt8u7RSAq6HdrUmpQlXcOc4v2qeSUhqIDxAfbxZIYqICH d54yWxgau7Iprmuu+ougxdrI3+DSh3pZBLDiBduJ/cUM5iJ4USJhu64AV mhiS0XNhfm8Ioz2DhMXkIcQDTfBe0vt16YKRRNMSAR5GPzFWZoQRhB3ga U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAHGJkVOtJA2F/2dsb2JhbABZgw2BK8N8AYEIFnWEAwEBAQMBHR00CwULAgEIEgYeEDIXDgIEDiCIHwjNABeJPoR4MweDK4EWBJoWk0CBfIFAgi8 X-IronPort-AV: E=Sophos;i="4.98,988,1392163200"; d="scan'208";a="331084441" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jun 2014 09:31:23 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s569VMH8027178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 09:31:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.85]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 04:31:22 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPSq40P8CAt6t4pEKHvEzjBJGgzZr3VmaAgF4dNgCABMzHAIAEsZwAgAWc2wCAAAPCgA== Date: Fri, 6 Jun 2014 09:31:21 +0000 Message-ID: References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201403281736.s2SHawV72952@magenta.juniper.net> <20140328212333.GE30644@juniper.net> <20140606091754.GB12354@juniper.net> In-Reply-To: <20140606091754.GB12354@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/UozrbiS5UR7t1VMO3Vp3xu5BkJM Cc: Yakov Rekhter , "Eric Vyncke \(evyncke\)" , "" , "John G. Scudder" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:32:14 -0000 On Jun 6, 2014, at 11:17 AM, Hannes Gredler wrote: > stefano, et al, >=20 > my read of SR and IPv6-SR in the past year is: >=20 > 1. that in 2013 you have started out with a *unified* control-plane > based on stacked-tunnels technology which supports more than > one data-plane. >=20 > 2. because it supports 'more than' dataplane and there is > a high congruency between dataplane forwarding semantics you need an > overarching, common 'architecture' with new terminology etc. >=20 > now lets have a closer look after more than one-year of 'SR-promised-land= ': >=20 > 1. There is little to no SP traction on IPv6-SR. the above statement reflects a lack of understanding of what's going on=20 at that particular side. I'd suggest you to have a better look. I think even on this list, operators expressed their interest in SR architecture=20 for v6 dataplane. Very recently we had an interesting presentation at NANOG. Maybe you=20 should have a look. > those SPs who have voiced support in all reality > can be served well with nested IP tunnels based on > exisiting protocols (GRE, IPIP, L2TPv3 ) This is what you keep publicly claiming... without really believing on it. > 2. For certain usecases (e.g. protection, OAM, controller-based TE, etc) > there is SP traction in SR-over-MPLS. >=20 > 3. There is little to no congruency in terms of forwarding-semantics > between the IPv6-SR dataplane and the MPLS data-plane. >=20 > a) MPLS forwarding > =3D loose and strict forwarding based on local assigned tags >=20 > b) IPv6-SR forwarding > =3D best-matching prefix forwarding based on global assigned adres= ses >=20 > 4. the cost of adding explicit routing forwarding capabilities > to IPv6 forwarding hardware is now visible (and guess what - its expe= nsive > to implement on high speed (100GBIT/s lookup engines - > (parsing IPv6-extensions headers does require a lot of memory referen= ces) >=20 > 5. IOW the need to support for 'more-than-one dataplane' has just shrunk= down > to 'one dataplane' of practical relevance (which is MPLS). >=20 > 6. for *one* practical dataplane we do not need new architecture, nor ne= w terminology. > all what is required is some further clarification to rfc3031, which > 'draft-gredler-spring-mpls' really is all about. draft-gredler-spring-mpls is the most complex solution to a very simple=20 requirement. I believe your draft is a very nice exercise so to prove=20 you can do source routing with something that was clearly not designed=20 to do so. With a very high price in terms of complexity (architectural=20 and operational) you mimic what SR does with much more simplicity. Your draft explains in more than 10 pages what SRs explains in 10 lines=20 and nobody changes anything in the mpls dataplane. Well, you know that, we've talked about it already, right ? > what really irritates me relax, enjoy the summer that's coming... > is your repeated delay tactics around publication on this mailing you already told me I'm a liar, now you state I'm doing=20 tactics... should I keep a counter ? > of 'IPv6-SR' in sufficient details, such that one can see the clear need = for a > *common* architecture. my trust that this will happen has gotten down to = almost zero. why are you so stressed ? The change that needs to be made in the 6man=20 draft is only about the adj-sid. a minor detail. Since you seem very stressed and obsessed about it, let me promise you=20 I will submit the draft today so you can have a more relax week-end. Obviously, only if this makes you feel better. s. > before asking the WG to adopt a common SR architecture and terminology > i'd rather ask you to *proof* the need for it. right now there > is *zero* evidence on the table that we need a 'common, dataplane neutral > SR architecture' at all, for supporting the practical relevant use-cases. >=20 > /hannes >=20 >=20 > On Mon, Jun 02, 2014 at 07:36:47PM +0000, Stefano Previdi (sprevidi) wrot= e: > [ ... ] >=20 > | > i hope it does not take another 12 months > | > (e.g. like the last time when we have asked for the data ipv6-sr plan= e specification > | > presented at mplswc2013 - actual publication data was feb 2014 ...) = - > |=20 > |=20 > | Indeed, SR-IPv6 was initially presented at mplswc2013, then it=20 > | triggered interest and collaboration from many parties. Note that=20 > | we met during a couple of hours in Paris at that time and we gave=20 > | you all the details of what we had in mind, including the ipv6=20 > | part.=20 > |=20 > | Then, at some point in the cycle, we published a draft describing=20 > | what the authors worked out in terms of architecture and SRH details.=20 > | I don't think I have to come with a justification about the amount=20 > | of time it took. > |=20 > | Anyway, in the mean time, implementation work from multiple parties=20 > | started (for both mpls and v6 dataplanes). Now that we have multiple=20 > | implementations, we are working on interoperability and we will,=20 > | probably, again update some of the details but don't take this as a=20 > | commitment from my side to publish anything in a delay that suits=20 > | your time perception.=20 > |=20 > |=20 > | s. From nobody Fri Jun 6 02:48:43 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC77F1A02C1 for ; Fri, 6 Jun 2014 02:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAbw4noT2k0G for ; Fri, 6 Jun 2014 02:48:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0AE1A0109 for ; Fri, 6 Jun 2014 02:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1629; q=dns/txt; s=iport; t=1402048114; x=1403257714; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=se+CSvtHcJKOg81CwNwROZ9EB5DayXLp9D71YcK0oe0=; b=Y0OhfgzAnH8cx5F/ygfZVliv5eOVsIb+Uq6B5uklBN++Xw8mGpOEcUPc +kx+cT47pf+JnRGvFxQOXV99Yc+jsXKSYuOkuRvVm8FQ1qKza6cTxF/7a F1ss+cUKfS1b9kY2RrvS142WrewlWmKsCwFw281qfl3Y2S0N8ba5/JIeK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FACKOkVOtJV2Z/2dsb2JhbABZgw2BK8N+AYEIFnWEAwEBAQMBHVwFCwIBCBguMiUCBAENBYg6CM0PF45pB4RBAQOJc5Ajk0CBfIFAgi8 X-IronPort-AV: E=Sophos;i="4.98,988,1392163200"; d="scan'208";a="330868031" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2014 09:48:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s569mCLV026772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 09:48:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 04:48:12 -0500 From: "Eric Vyncke (evyncke)" To: Hannes Gredler , "Stefano Previdi (sprevidi)" Thread-Topic: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPgWg5bT4XHnCkrkSvUKZV7strC5tkS2OA Date: Fri, 6 Jun 2014 09:48:12 +0000 Message-ID: References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201403281736.s2SHawV72952@magenta.juniper.net> <20140328212333.GE30644@juniper.net> <20140606091754.GB12354@juniper.net> In-Reply-To: <20140606091754.GB12354@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.55.185.75] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <398B5670D945F44EB6BE24D679A467DB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/69T2XFu5SC0P1v49wkG19gZiPpk Cc: Yakov Rekhter , "" , "John G. Scudder" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:48:41 -0000 Hannes, I am following this thread from far away but I wonder about: On 6/06/14 11:17, "Hannes Gredler" wrote: > > 1. There is little to no SP traction on IPv6-SR. > those SPs who have voiced support in all reality > can be served well with nested IP tunnels based on > exisiting protocols (GRE, IPIP, L2TPv3 ) Tunnels are also expensive (cfr point below) but if you want to enforce a specific route for TE, then, I am afraid that this will be a lot of specific configuration (or states if dynamic) in a lot of nodes... As well as a lot of specific routes towards those tunnels. So, kind of heavy. Not to mention that with SRH you could have different paths among two end-points based on the application (web vs video) identified by some means (such as layer-4 information), way more complex to do it with tunnels and 'plain' routing. > 4. the cost of adding explicit routing forwarding capabilities > to IPv6 forwarding hardware is now visible (and guess what - its >expensive > to implement on high speed (100GBIT/s lookup engines - > (parsing IPv6-extensions headers does require a lot of memory >references) I am sure that you know how source routing works, only the router in the destination address main IPv6 header field needs to inspect the SR header, all others routers can safely act only on the DA and ignoring the extension header chain (of course, if ACL are applied on layer-4 you need to parse the extension header chain but this is the same with or without SR). Hope that my comment helps clarifying the context -=E9ric From nobody Fri Jun 6 03:24:23 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11441A045E for ; Fri, 6 Jun 2014 03:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxmVXxitJK00 for ; Fri, 6 Jun 2014 03:24:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894451A0455 for ; Fri, 6 Jun 2014 03:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=290; q=dns/txt; s=iport; t=1402050254; x=1403259854; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YN0xoTuVmzba8MiBgC2Pv6I5F/9CAkQhUYnoq7g3TQM=; b=Y0zTEZHTZvVvzDtHsBshgejL75yXjEJ/KcO7OM9bwXYIM2rcUkeh4qzh W/qaB7h/q4oPDXQUH73bHOmF2mPONTTdXfMJS7CcioF9Fne9CJjrFhgsy KOQ3td+DxI+m+fhlE7ro8xRniD0KKbz1+El5HFNVu8XB0fVdlFZyxi/K5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFOWkVOtJA2L/2dsb2JhbABZgw1SWcUGFnWECjpRAT5CHwgEiFUNngOuaReSG4EWBJoWgUGRf4M8gi8 X-IronPort-AV: E=Sophos;i="4.98,988,1392163200"; d="scan'208";a="330874001" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2014 10:24:13 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s56AODvw024431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Jun 2014 10:24:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.85]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 05:24:13 -0500 From: "Stefano Previdi (sprevidi)" To: " ietf.org" Thread-Topic: new version of segment routing drafts Thread-Index: AQHPgXF1FO+ujpnPi0qAowMww9UgPg== Date: Fri, 6 Jun 2014 10:24:12 +0000 Message-ID: <1CECF204-9CEB-41CF-AECE-33AEF49479D6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.21] Content-Type: text/plain; charset="us-ascii" Content-ID: <5589E285E619EB44993267007219795B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/QNyn0aoYmT1Ncum248tDJ_AOXdM Subject: [spring] new version of segment routing drafts X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 10:24:21 -0000 All, we just submitted new versions of the following drafts: http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls-02=20 http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-03 The only substantial change is the addition of illustrative examples. s. From nobody Fri Jun 6 04:32:09 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6981A1A0436 for ; Fri, 6 Jun 2014 04:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1rV6P5KzgKG for ; Fri, 6 Jun 2014 04:32:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600921A0237 for ; Fri, 6 Jun 2014 04:32:06 -0700 (PDT) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (10.255.84.38) by DM2PR05MB749.namprd05.prod.outlook.com (10.141.178.140) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 6 Jun 2014 11:31:58 +0000 Received: from juniper.net (193.110.55.18) by pod51010.outlook.com (10.255.84.38) with Microsoft SMTP Server (TLS) id 14.16.459.0; Fri, 6 Jun 2014 11:31:56 +0000 Date: Fri, 6 Jun 2014 13:31:51 +0200 From: Hannes Gredler To: "Eric Vyncke (evyncke)" Message-ID: <20140606113151.GA13188@juniper.net> References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201403281736.s2SHawV72952@magenta.juniper.net> <20140328212333.GE30644@juniper.net> <20140606091754.GB12354@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.55.18] X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 023495660C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(479174003)(199002)(189002)(50466002)(86362001)(23726002)(83072002)(85852003)(92566001)(71816001)(81542001)(81342001)(92726001)(19580395003)(19580405001)(83322001)(99396002)(46406003)(101416001)(102836001)(74662001)(97756001)(87936001)(46102001)(66066001)(80022001)(47776003)(20776003)(64706001)(15202345003)(54356999)(76176999)(33656002)(79102001)(36756003)(83506001)(50986999)(15975445006)(31966008)(74502001)(76482001)(93886002)(21056001)(4396001)(77982001)(579124002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB749; H:BY2PRD0510HT003.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/kzKkXP7RQQUB7rArRaq969Jz238 Cc: Yakov Rekhter , "" , "John G. Scudder" , "Stefano Previdi \(sprevidi\)" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 11:32:08 -0000 hi eric, see answers inline. On Fri, Jun 06, 2014 at 09:48:12AM +0000, Eric Vyncke (evyncke) wrote: | Hannes, | | I am following this thread from far away but I wonder about: | | On 6/06/14 11:17, "Hannes Gredler" wrote: | > | > 1. There is little to no SP traction on IPv6-SR. | > those SPs who have voiced support in all reality | > can be served well with nested IP tunnels based on | > exisiting protocols (GRE, IPIP, L2TPv3 ) | | Tunnels are also expensive (cfr point below) but if you want to enforce a | specific route for TE, then, I am afraid that this will be a lot of | specific configuration (or states if dynamic) in a lot of nodes... As well | as a lot of specific routes towards those tunnels. So, kind of heavy. ^^^^^^^^^^^^^ depends a whole lot how you implement IP tunnels. if you follow the prevailing model that an IP tunnel is implemented as a logical-interface, (and hence needs to be explicitly configured) then you're right its heavy weight and expensive. however, it does not have to be like that: one could have e.g. an implementation where all inbound tunneled traffic is routed towards a decapulator-interface (where you do all the key validation, ACL etc.) which POPs of the outer tunnel header and does an IP lookup on the next-tunnel-header. so assuming this 'IP-tunnel-decapsulator' in core-nodes then any ingress node could describe an explicit path by pushing N nested IP tunnels. | Not to mention that with SRH you could have different paths among two | end-points based on the application (web vs video) identified by some | means (such as layer-4 information), way more complex to do it with | tunnels and 'plain' routing. see above: applications actually could do the nested-tunnel-pushing, using exisiting OS kernels. | > 4. the cost of adding explicit routing forwarding capabilities | > to IPv6 forwarding hardware is now visible (and guess what - its | >expensive | > to implement on high speed (100GBIT/s lookup engines - | > (parsing IPv6-extensions headers does require a lot of memory | >references) | | I am sure that you know how source routing works, only the router in the | destination address main IPv6 header field needs to inspect the SR header, | all others routers can safely act only on the DA and ignoring the | extension header chain (of course, if ACL are applied on layer-4 you need | to parse the extension header chain but this is the same with or without | SR). see and that is the problem here ... http://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-00 "Each segment endpoint inspects the SRH, updates the DA (with the next segment) and forwards the packet towards the next segment." this adds the requirement to rewrite the IPv6-DA. i'd estimate that the majority of IP6 hardware forwarding implementations does not have the ability to *rewrite* IPv6 DAs (perhaps on the edge thatre are some CG-NAT chipsets which can do this). /hannes From nobody Fri Jun 6 05:29:08 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AD41A0068 for ; Fri, 6 Jun 2014 05:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToLRoT4EYW1T for ; Fri, 6 Jun 2014 05:29:04 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EC21A0479 for ; Fri, 6 Jun 2014 05:29:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id D3C541B69E4; Fri, 6 Jun 2014 14:28:34 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm0murWX1esi; Fri, 6 Jun 2014 14:28:34 +0200 (CEST) Received: from ams3-vpn-dhcp2284.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 0EB341B69E3; Fri, 6 Jun 2014 14:28:33 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB63EE6D-30F7-47A8-8736-898FE443C7E2" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pierre Francois In-Reply-To: Date: Fri, 6 Jun 2014 14:28:52 +0200 Message-Id: <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> To: Anoop Ghanwani X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/VBfEUSvjZjYq3LKsvvCvp0MEvaI Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 12:29:07 -0000 --Apple-Mail=_EB63EE6D-30F7-47A8-8736-898FE443C7E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Anoop,=20 In path protection, section 2, the packets will be dropped until the = ingress node decides to stop using the failed path and failover.=20 In all other sections, the packets are to be rerouted directly by the = nodes adjacent to the failed component. Cheers,=20 Pierre. On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani = wrote: > I have a question about this draft. >=20 > In section 2, it has the following statement: > >>> > >=46rom a SPRING viewpoint, we would like to highlight the following > requirement: the two configured paths T1 and T2 MUST NOT benefit from > local protection. > >>> >=20 > But there is no such statement in subsequent sections. >=20 > So suppose I have a data packet using SPRING to use path A - B - C. = If B is down, would such packets be discarded or would there be an = attempt to get it to C if one of the other methods for repair is = configured? >=20 > Anoop >=20 > On Tue, May 13, 2014 at 9:35 AM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF. >=20 > Title : Use-cases for Resiliency in SPRING > Authors : Pierre Francois > Clarence Filsfils > Bruno Decraene > Rob Shakir > Filename : = draft-ietf-spring-resiliency-use-cases-00.txt > Pages : 8 > Date : 2014-05-12 >=20 > Abstract: > This document describes the use cases for resiliency in SPRING > networks. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_EB63EE6D-30F7-47A8-8736-898FE443C7E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 anoop@alumni.duke.edu> = wrote:
I have a question about this = draft.

In section 2, it has the following = statement:
>>>
>=46rom=
 a SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local =
protection.
>>>

But there is no such statement in subsequent = sections.

So suppose I have a data packet using SPRING to = use path A - B - C.  If B is down, would such packets be discarded = or would there be an attempt to get it to C if one of the other methods = for repair is configured?

Anoop

On Tue, = May 13, 2014 at 9:35 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Source Packet Routing in = Networking Working Group of the IETF.

        Title           : = Use-cases for Resiliency in SPRING
        Authors         : Pierre = Francois
                    =       Clarence Filsfils
                    =       Bruno Decraene
                    =       Rob Shakir
        Filename        : = draft-ietf-spring-resiliency-use-cases-00.txt
        Pages           : = 8
        Date           =  : 2014-05-12

Abstract:
   This document describes the use cases for resiliency in = SPRING
   networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-resil= iency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resiliency-= use-cases-00


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.or= g/mailman/listinfo/spring

= --Apple-Mail=_EB63EE6D-30F7-47A8-8736-898FE443C7E2-- From nobody Fri Jun 6 06:18:07 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E01A048F for ; Fri, 6 Jun 2014 06:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI1cEwCe5Y9Q for ; Fri, 6 Jun 2014 06:18:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BA21A008E for ; Fri, 6 Jun 2014 06:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3715; q=dns/txt; s=iport; t=1402060678; x=1403270278; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uddxkkihLX7Tz30Ej0Yh4QhzziCTpOMbydQDm59nZ/c=; b=fgVJmhYhKPK0ROGj2a4v69/4SP1mJltS/X605DJRT9xqyos/WT5TRLVG bZbHhr++VjyQZtCY+Z/N8PVuORzbBJ8VDU95PeBFUheGwHNqWMVcJgr8u 0Ai/QNyvSDFkPf10tpvOFOL64cbAIMxwsA3TJs6gsokS3iyF5OSvPUrvG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFACy+kVOtJA2L/2dsb2JhbABZgw1SWcN/AYEGFnWEAwEBAQQdHT8QAgEIEgYeEDIXDgIEDgWIQg3NGxeONjMHgyuBFgSaFoFBkX+BfIFAgW8kHA X-IronPort-AV: E=Sophos;i="4.98,989,1392163200"; d="scan'208";a="331185263" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jun 2014 13:17:56 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s56DHubl031305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 13:17:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.85]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 08:17:55 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPSq40P8CAt6t4pEKHvEzjBJGgzZr3VmaAgF4dNgCABMzHAIAEsZwAgAWc2wCAAAh3AIAAHPaAgAAdngA= Date: Fri, 6 Jun 2014 13:17:55 +0000 Message-ID: References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201403281736.s2SHawV72952@magenta.juniper.net> <20140328212333.GE30644@juniper.net> <20140606091754.GB12354@juniper.net> <20140606113151.GA13188@juniper.net> In-Reply-To: <20140606113151.GA13188@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.33] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/cYtXXReUr704LzteJ2YXxYOvXBI Cc: Yakov Rekhter , "Eric Vyncke \(evyncke\)" , "" , "John G. Scudder" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 13:18:06 -0000 On Jun 6, 2014, at 1:31 PM, Hannes Gredler wrote: > hi eric, >=20 > see answers inline. >=20 > On Fri, Jun 06, 2014 at 09:48:12AM +0000, Eric Vyncke (evyncke) wrote: > | Hannes, > |=20 > | I am following this thread from far away but I wonder about: > |=20 > | On 6/06/14 11:17, "Hannes Gredler" wrote: > | > > | > 1. There is little to no SP traction on IPv6-SR. > | > those SPs who have voiced support in all reality > | > can be served well with nested IP tunnels based on > | > exisiting protocols (GRE, IPIP, L2TPv3 ) > |=20 > | Tunnels are also expensive (cfr point below) but if you want to enforce= a > | specific route for TE, then, I am afraid that this will be a lot of > | specific configuration (or states if dynamic) in a lot of nodes... As w= ell > | as a lot of specific routes towards those tunnels. So, kind of heavy. > ^^^^^^^^^^^^^ >=20 > depends a whole lot how you implement IP tunnels. > if you follow the prevailing model that an IP tunnel is implemented as a= logical-interface, > (and hence needs to be explicitly configured) then you're right its heav= y weight and > expensive. >=20 > however, it does not have to be like that: > one could have e.g. an implementation where all inbound tunneled traffic= is routed > towards a decapulator-interface (where you do all the key validation, AC= L etc.) > which POPs of the outer tunnel header and > does an IP lookup on the next-tunnel-header. >=20 > so assuming this 'IP-tunnel-decapsulator' in core-nodes then any ingress = node > could describe an explicit path by pushing N nested IP tunnels. >=20 > | Not to mention that with SRH you could have different paths among two > | end-points based on the application (web vs video) identified by some > | means (such as layer-4 information), way more complex to do it with > | tunnels and 'plain' routing. >=20 > see above: applications actually could do the nested-tunnel-pushing, > using exisiting OS kernels. >=20 > | > 4. the cost of adding explicit routing forwarding capabilities > | > to IPv6 forwarding hardware is now visible (and guess what - its > | >expensive > | > to implement on high speed (100GBIT/s lookup engines - > | > (parsing IPv6-extensions headers does require a lot of memory > | >references) > |=20 > | I am sure that you know how source routing works, only the router in th= e > | destination address main IPv6 header field needs to inspect the SR head= er, > | all others routers can safely act only on the DA and ignoring the > | extension header chain (of course, if ACL are applied on layer-4 you ne= ed > | to parse the extension header chain but this is the same with or withou= t > | SR). >=20 > see and that is the problem here ... >=20 > http://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-00 >=20 > "Each segment endpoint inspects the SRH, updates the DA (with the next > segment) and forwards the packet towards the next segment." >=20 > this adds the requirement to rewrite the IPv6-DA. > i'd estimate that the majority of IP6 hardware forwarding implementations > does not have the ability to *rewrite* IPv6 DAs (perhaps on the edge > thatre are some CG-NAT chipsets which can do this). I'd leave you with your estimation however I'd like to point out=20 that the behavior consisting of rewriting the DA at a segment endpoint=20 has not been defined by Segment Routing but rather by IPv6 architecture=20 (rfc2460). Segment Routing just leverages an architectural component=20 defined a few years back. s. >=20 > /hannes From nobody Fri Jun 6 07:30:55 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877241A0108 for ; Fri, 6 Jun 2014 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGneqMYQN874 for ; Fri, 6 Jun 2014 07:30:51 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FD61A0152 for ; Fri, 6 Jun 2014 07:30:50 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so150982wes.39 for ; Fri, 06 Jun 2014 07:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6KdKxfTWth3N0MKQRxuumTyZLCqB0kp75huqMGzSeRE=; b=dg7O9KNpCJZrnN82/9UVMJ3fIIl1hrGrpnYgfv7VIa3X0nl1aXt4Qb3pZDB9qwqFTl EcybOHRUU2p7tCZtLcdKJtbhwIe1bbNAwVI4zKC2V9z0JP3+QouF+Kh0qIDY8ny42B5d vWo2oHaOy3NnFAMIZHvkgxfxB0snAe2/7AvGs8SMEYkjpOzf7T0cI9BHCnxnYAEPIM+l bWPFVKoEHmV2FfKnnvAVp2FIuPRGvgwRpqL04q/m2GoYPkZCribFYx9qY4JMLIQ3hy6x eDnxBs+u3hLKphbXTNRnETvro+JW7KJbjwbrbWqU9yQzQtJGeYOXP0VEdIZc3d0XdZal IPow== MIME-Version: 1.0 X-Received: by 10.180.73.201 with SMTP id n9mr8463285wiv.45.1402065042634; Fri, 06 Jun 2014 07:30:42 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.182.67 with HTTP; Fri, 6 Jun 2014 07:30:42 -0700 (PDT) In-Reply-To: <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> Date: Fri, 6 Jun 2014 07:30:42 -0700 X-Google-Sender-Auth: fC_cBOal2BgXU2Hx7YBT-AA-wDQ Message-ID: From: Anoop Ghanwani To: Pierre Francois Content-Type: multipart/alternative; boundary=f46d0435c02ad21a9f04fb2bb43b Archived-At: http://mailarchive.ietf.org/arch/msg/spring/dCW0JJIME18f1bmmRw1sdl39Y8c Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:30:52 -0000 --f46d0435c02ad21a9f04fb2bb43b Content-Type: text/plain; charset=ISO-8859-1 Thanks Pierre. What if the failed component is one of the explicitly identified hops? Anoop On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois wrote: > > Hello Anoop, > > In path protection, section 2, the packets will be dropped until the > ingress node decides to stop using the failed path and failover. > > In all other sections, the packets are to be rerouted directly by the > nodes adjacent to the failed component. > > Cheers, > > Pierre. > > On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani wrote: > > I have a question about this draft. > > In section 2, it has the following statement: > >>> > > >From a SPRING viewpoint, we would like to highlight the following > requirement: the two configured paths T1 and T2 MUST NOT benefit from > local protection. > > >>> > > But there is no such statement in subsequent sections. > > So suppose I have a data packet using SPRING to use path A - B - C. If B > is down, would such packets be discarded or would there be an attempt to > get it to C if one of the other methods for repair is configured? > > Anoop > > On Tue, May 13, 2014 at 9:35 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Source Packet Routing in Networking >> Working Group of the IETF. >> >> Title : Use-cases for Resiliency in SPRING >> Authors : Pierre Francois >> Clarence Filsfils >> Bruno Decraene >> Rob Shakir >> Filename : draft-ietf-spring-resiliency-use-cases-00.txt >> Pages : 8 >> Date : 2014-05-12 >> >> Abstract: >> This document describes the use cases for resiliency in SPRING >> networks. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --f46d0435c02ad21a9f04fb2bb43b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Pierre.

What if the failed compo= nent is one of the explicitly identified hops?

Ano= op


On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <pierre.francois@= imdea.org> wrote:
Hello Anoop,=A0

In path protection, section 2, th= e packets will be dropped until the ingress node decides to stop using the = failed path and failover.=A0

In all other sections, the packets are to be rerouted d= irectly by the nodes adjacent to the failed component.

=
Cheers,=A0

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
I have a question about this d= raft.

In section 2, it has the following statement:
>= >>
>From a SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local protection.
>>>

But there is no such statement in subsequent sectio= ns.

So= suppose I have a data packet using SPRING to use path A - B - C. =A0If B i= s down, would such packets be discarded or would there be an attempt to get= it to C if one of the other methods for repair is configured?

Anoop
On Tue, May 13, 2014 at 9:35 AM, <int= ernet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Source Packet Routing in Networking Wor= king Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Use-cases for Resiliency in SPR= ING
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Pierre Francois
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clarence Filsfils
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bruno Decraene
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rob Shakir
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-spring-resiliency-use-= cases-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-05-12

Abstract:
=A0 =A0This document describes the use cases for resiliency in SPRING
=A0 =A0networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spr= ing-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resili= ency-use-cases-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring


--f46d0435c02ad21a9f04fb2bb43b-- From nobody Fri Jun 6 07:38:33 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238021A0495 for ; Fri, 6 Jun 2014 07:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rF7ycWayg9L for ; Fri, 6 Jun 2014 07:38:29 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61C61A046F for ; Fri, 6 Jun 2014 07:38:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id D581C1B724B; Fri, 6 Jun 2014 16:37:59 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnwQnzzAierj; Fri, 6 Jun 2014 16:37:59 +0200 (CEST) Received: from ams3-vpn-dhcp2284.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 11ACB1B724A; Fri, 6 Jun 2014 16:37:58 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF29D55-57F3-4CA3-B4AE-CD5A6E713389" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pierre Francois In-Reply-To: Date: Fri, 6 Jun 2014 16:38:18 +0200 Message-Id: <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> To: Anoop Ghanwani X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Aopqk_QgtSeQ5552JzIdElPeX7s Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:38:32 -0000 --Apple-Mail=_4CF29D55-57F3-4CA3-B4AE-CD5A6E713389 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Anoop,=20 You loose the traffic until the moment the ingress node falls back on = another path.=20 If you don't want to have to wait for that failover to happen, then your = use-case is in another section than the one using path protection ;) Pierre. On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani = wrote: > Thanks Pierre. >=20 > What if the failed component is one of the explicitly identified hops? >=20 > Anoop >=20 >=20 > On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = wrote: >=20 > Hello Anoop,=20 >=20 > In path protection, section 2, the packets will be dropped until the = ingress node decides to stop using the failed path and failover.=20 >=20 > In all other sections, the packets are to be rerouted directly by the = nodes adjacent to the failed component. >=20 > Cheers,=20 >=20 > Pierre. >=20 > On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani = wrote: >=20 >> I have a question about this draft. >>=20 >> In section 2, it has the following statement: >> >>> >> >=46rom a SPRING viewpoint, we would like to highlight the following >> requirement: the two configured paths T1 and T2 MUST NOT benefit from >> local protection. >> >>> >>=20 >> But there is no such statement in subsequent sections. >>=20 >> So suppose I have a data packet using SPRING to use path A - B - C. = If B is down, would such packets be discarded or would there be an = attempt to get it to C if one of the other methods for repair is = configured? >>=20 >> Anoop >>=20 >> On Tue, May 13, 2014 at 9:35 AM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF. >>=20 >> Title : Use-cases for Resiliency in SPRING >> Authors : Pierre Francois >> Clarence Filsfils >> Bruno Decraene >> Rob Shakir >> Filename : = draft-ietf-spring-resiliency-use-cases-00.txt >> Pages : 8 >> Date : 2014-05-12 >>=20 >> Abstract: >> This document describes the use cases for resiliency in SPRING >> networks. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_4CF29D55-57F3-4CA3-B4AE-CD5A6E713389 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 anoop@alumni.duke.edu> = wrote:
Thanks Pierre.

What if = the failed component is one of the explicitly identified = hops?

Anoop


On Fri, Jun 6, = 2014 at 5:28 AM, Pierre Francois <pierre.francois@imdea.org> wrote:

Hello = Anoop, 

In path protection, section 2, the = packets will be dropped until the ingress node decides to stop using the = failed path and failover. 

In all other sections, the packets are to be = rerouted directly by the nodes adjacent to the failed = component.

Cheers, 

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> = wrote:

I have a = question about this draft.

In section 2, it has the following = statement:
>>>
>=46rom a =
SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local =
protection.
>>>

But there is no such statement in subsequent = sections.

So suppose I have a data packet using SPRING to = use path A - B - C.  If B is down, would such packets be discarded = or would there be an attempt to get it to C if one of the other methods = for repair is configured?

Anoop

On Tue, = May 13, 2014 at 9:35 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Source Packet Routing in = Networking Working Group of the IETF.

        Title           : = Use-cases for Resiliency in SPRING
        Authors         : Pierre = Francois
                    =       Clarence Filsfils
                    =       Bruno Decraene
                    =       Rob Shakir
        Filename        : = draft-ietf-spring-resiliency-use-cases-00.txt
        Pages           : = 8
        Date           =  : 2014-05-12

Abstract:
   This document describes the use cases for resiliency in = SPRING
   networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-resil= iency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resiliency-= use-cases-00


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.or= g/mailman/listinfo/spring

= --Apple-Mail=_4CF29D55-57F3-4CA3-B4AE-CD5A6E713389-- From nobody Fri Jun 6 07:45:34 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F161A010D for ; Fri, 6 Jun 2014 07:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJFRwjJk9U0r for ; Fri, 6 Jun 2014 07:45:31 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5D51A046F for ; Fri, 6 Jun 2014 07:45:31 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so2886319wes.6 for ; Fri, 06 Jun 2014 07:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ui3frzyby0pXpbF22kYqjcejr8571bR9OdXxXSei0sU=; b=AKVkvHKpYF9VI5tz854EOemhjONZ3t0rZ/V9RzybdH6h6aFAe5Qobqfkf9wl9lXXVJ 1lB79Z13RRy8+tHz7tHGUO3LSzmCr8h4UHYQdR3AFJwyAnFd9Wg5oGuVMAX1h2c+QVvy JJTHByry8/fDY6L67A5GS7VtTAxGlBd7eF/GGfpRAN+T1S1MLIzn7FlBpuleDfP8UUP4 tiDh3tHSGzX3Gr14Z0PFX0kaofXaAdpI2AM+G2F4eZLIIFaRuyLaAgMgYaWYjlCMJV9i S1Wwup2QCnJrxqi1dh8Fqy5gjpxwMuzdSMyfDzeyNkC9QsOwfwj5K/a9y3NDmtzPBEus sjZw== MIME-Version: 1.0 X-Received: by 10.195.13.79 with SMTP id ew15mr7624213wjd.19.1402065923220; Fri, 06 Jun 2014 07:45:23 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.182.67 with HTTP; Fri, 6 Jun 2014 07:45:23 -0700 (PDT) In-Reply-To: <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> Date: Fri, 6 Jun 2014 07:45:23 -0700 X-Google-Sender-Auth: _4dIgPMozAPrEmLNOKBk9FdaIFw Message-ID: From: Anoop Ghanwani To: Pierre Francois Content-Type: multipart/alternative; boundary=047d7bfd093a4e295504fb2be98a Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Cucg0Cs1PT0IyhlSLq3LvwqiZPI Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:45:33 -0000 --047d7bfd093a4e295504fb2be98a Content-Type: text/plain; charset=ISO-8859-1 Pierre, My question is more from a security standpoint. If a node is explicitly identified in the path and that node is down, is it OK to route around it. I guess what I'm hearing you say is that it depends on what the network operator has configured. They can choose to either discard all such packets, or route all such packets around the failure, but they cannot choose what it to be done on a per-packet basis. Do I have that right? Anoop On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois wrote: > > Anoop, > > You loose the traffic until the moment the ingress node falls back on > another path. > > If you don't want to have to wait for that failover to happen, then your > use-case is in another section than the one using path protection ;) > > Pierre. > > > > On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani wrote: > > Thanks Pierre. > > What if the failed component is one of the explicitly identified hops? > > Anoop > > > On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois > wrote: > >> >> Hello Anoop, >> >> In path protection, section 2, the packets will be dropped until the >> ingress node decides to stop using the failed path and failover. >> >> In all other sections, the packets are to be rerouted directly by the >> nodes adjacent to the failed component. >> >> Cheers, >> >> Pierre. >> >> On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani wrote: >> >> I have a question about this draft. >> >> In section 2, it has the following statement: >> >>> >> >> >From a SPRING viewpoint, we would like to highlight the following >> requirement: the two configured paths T1 and T2 MUST NOT benefit from >> local protection. >> >> >>> >> >> But there is no such statement in subsequent sections. >> >> So suppose I have a data packet using SPRING to use path A - B - C. If B >> is down, would such packets be discarded or would there be an attempt to >> get it to C if one of the other methods for repair is configured? >> >> Anoop >> >> On Tue, May 13, 2014 at 9:35 AM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Source Packet Routing in Networking >>> Working Group of the IETF. >>> >>> Title : Use-cases for Resiliency in SPRING >>> Authors : Pierre Francois >>> Clarence Filsfils >>> Bruno Decraene >>> Rob Shakir >>> Filename : draft-ietf-spring-resiliency-use-cases-00.txt >>> Pages : 8 >>> Date : 2014-05-12 >>> >>> Abstract: >>> This document describes the use cases for resiliency in SPRING >>> networks. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --047d7bfd093a4e295504fb2be98a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Pierre,

My question is more from a secu= rity standpoint.

If a node is explicitly identifie= d in the path and that node is down, is it OK to route around it.

I guess what I'm hearing you say is that it depends on w= hat the network operator has configured. =A0They can choose to either disca= rd all such packets, or route all such packets around the failure, but they= cannot choose what it to be done on a per-packet basis. =A0Do I have that = right?

Anoop


On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <pierre.francois@imdea.org> wrote:
Anoop,=A0

You loose the traffic until the m= oment the ingress node falls back on another path.=A0

If you don't want to have to wait for that failover to h= appen, then your use-case is in another section than the one using path pro= tection ;)

Pierre.



On= Jun 6, 2014, at 4:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Thanks Pierre.

What if the failed component is one of the explicitly identified hops= ?

Anoop

=
On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = <pierre.francois@imdea.org> wrote:
Hello Anoop,=A0

In path protection, section 2, th= e packets will be dropped until the ingress node decides to stop using the = failed path and failover.=A0

In all other sections, the packets are to be rerouted d= irectly by the nodes adjacent to the failed component.

=
Cheers,=A0

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
I have a question about this d= raft.

In section 2, it has the following statement:
>= >>
>From a SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local protection.
>>>

But there is no such statement in subsequent sectio= ns.

So= suppose I have a data packet using SPRING to use path A - B - C. =A0If B i= s down, would such packets be discarded or would there be an attempt to get= it to C if one of the other methods for repair is configured?

Anoop
On Tue, May 13, 2014 at 9:35 AM, <int= ernet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Source Packet Routing in Networking Wor= king Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Use-cases for Resiliency in SPR= ING
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Pierre Francois
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clarence Filsfils
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bruno Decraene
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rob Shakir
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-spring-resiliency-use-= cases-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-05-12

Abstract:
=A0 =A0This document describes the use cases for resiliency in SPRING
=A0 =A0networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spr= ing-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resili= ency-use-cases-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring


--047d7bfd093a4e295504fb2be98a-- From nobody Fri Jun 6 07:54:58 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C4B1A04B7 for ; Fri, 6 Jun 2014 07:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK9MO4cChZPh for ; Fri, 6 Jun 2014 07:54:47 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD091A0537 for ; Fri, 6 Jun 2014 07:54:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 716E31B736D; Fri, 6 Jun 2014 16:53:36 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EzEaneDEfJd; Fri, 6 Jun 2014 16:53:36 +0200 (CEST) Received: from ams3-vpn-dhcp2284.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 970911B736C; Fri, 6 Jun 2014 16:53:35 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F397FA04-D683-4C38-BC0D-E56FE990E896" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pierre Francois In-Reply-To: Date: Fri, 6 Jun 2014 16:53:54 +0200 Message-Id: <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> To: Anoop Ghanwani X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/cI-_rGuuhXj2HAde8vs3nr3Ibxo Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:54:56 -0000 --Apple-Mail=_F397FA04-D683-4C38-BC0D-E56FE990E896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Anoop,=20 Well, we have this requirement to be able to have both approaches doable = at the same time on the same network...=20 For example, in SR, you can encode configure your segments as to be = protected, or not.=20 If you want local protection, configure segments to be locally = protected.=20 If you want path protection, configure segments to not be locally = protected.=20 If you need both for two different services, you'd configure both types = and pick the ones that match the service you need.=20 Cheers,=20 Pierre. On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani = wrote: > Pierre, >=20 > My question is more from a security standpoint. >=20 > If a node is explicitly identified in the path and that node is down, = is it OK to route around it. >=20 > I guess what I'm hearing you say is that it depends on what the = network operator has configured. They can choose to either discard all = such packets, or route all such packets around the failure, but they = cannot choose what it to be done on a per-packet basis. Do I have that = right? >=20 > Anoop >=20 >=20 > On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois = wrote: >=20 > Anoop,=20 >=20 > You loose the traffic until the moment the ingress node falls back on = another path.=20 >=20 > If you don't want to have to wait for that failover to happen, then = your use-case is in another section than the one using path protection = ;) >=20 > Pierre. >=20 >=20 >=20 > On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani = wrote: >=20 >> Thanks Pierre. >>=20 >> What if the failed component is one of the explicitly identified = hops? >>=20 >> Anoop >>=20 >>=20 >> On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = wrote: >>=20 >> Hello Anoop,=20 >>=20 >> In path protection, section 2, the packets will be dropped until the = ingress node decides to stop using the failed path and failover.=20 >>=20 >> In all other sections, the packets are to be rerouted directly by the = nodes adjacent to the failed component. >>=20 >> Cheers,=20 >>=20 >> Pierre. >>=20 >> On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani = wrote: >>=20 >>> I have a question about this draft. >>>=20 >>> In section 2, it has the following statement: >>> >>> >>> >=46rom a SPRING viewpoint, we would like to highlight the following >>> requirement: the two configured paths T1 and T2 MUST NOT benefit = from >>> local protection. >>> >>> >>>=20 >>> But there is no such statement in subsequent sections. >>>=20 >>> So suppose I have a data packet using SPRING to use path A - B - C. = If B is down, would such packets be discarded or would there be an = attempt to get it to C if one of the other methods for repair is = configured? >>>=20 >>> Anoop >>>=20 >>> On Tue, May 13, 2014 at 9:35 AM, wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Source Packet Routing in = Networking Working Group of the IETF. >>>=20 >>> Title : Use-cases for Resiliency in SPRING >>> Authors : Pierre Francois >>> Clarence Filsfils >>> Bruno Decraene >>> Rob Shakir >>> Filename : = draft-ietf-spring-resiliency-use-cases-00.txt >>> Pages : 8 >>> Date : 2014-05-12 >>>=20 >>> Abstract: >>> This document describes the use cases for resiliency in SPRING >>> networks. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>>=20 >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>=20 >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_F397FA04-D683-4C38-BC0D-E56FE990E896 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 anoop@alumni.duke.edu> = wrote:
Pierre,

My question is = more from a security standpoint.

If a node is = explicitly identified in the path and that node is down, is it OK to = route around it.

I guess what I'm hearing you say is that it depends on = what the network operator has configured.  They can choose to = either discard all such packets, or route all such packets around the = failure, but they cannot choose what it to be done on a per-packet = basis.  Do I have that right?

Anoop


On Fri, Jun 6, = 2014 at 7:38 AM, Pierre Francois <pierre.francois@imdea.org> wrote:

Anoop, 
=
You loose the traffic until the moment the ingress node falls = back on another path. 

If you don't want to have to wait for that failover to = happen, then your use-case is in another section than the one using path = protection ;)

Pierre.



On Jun 6, 2014, at = 4:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Thanks = Pierre.

What if the failed component is one of the = explicitly identified = hops?

Anoop


On Fri, Jun 6, 2014 at 5:28 AM, Pierre = Francois <pierre.francois@imdea.org> wrote:

Hello = Anoop, 

In path protection, section 2, the = packets will be dropped until the ingress node decides to stop using the = failed path and failover. 

In all other sections, the packets are to be = rerouted directly by the nodes adjacent to the failed = component.

Cheers, 

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> = wrote:

I have a = question about this draft.

In section 2, it has the following = statement:
>>>
>=46rom a =
SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local =
protection.
>>>

But there is no such statement in subsequent = sections.

So suppose I have a data packet using SPRING to = use path A - B - C.  If B is down, would such packets be discarded = or would there be an attempt to get it to C if one of the other methods = for repair is configured?

Anoop

On Tue, = May 13, 2014 at 9:35 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Source Packet Routing in = Networking Working Group of the IETF.

        Title           : = Use-cases for Resiliency in SPRING
        Authors         : Pierre = Francois
                    =       Clarence Filsfils
                    =       Bruno Decraene
                    =       Rob Shakir
        Filename        : = draft-ietf-spring-resiliency-use-cases-00.txt
        Pages           : = 8
        Date           =  : 2014-05-12

Abstract:
   This document describes the use cases for resiliency in = SPRING
   networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-resil= iency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resiliency-= use-cases-00


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
=


_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.or= g/mailman/listinfo/spring

= --Apple-Mail=_F397FA04-D683-4C38-BC0D-E56FE990E896-- From nobody Fri Jun 6 09:10:18 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832631A010D for ; Fri, 6 Jun 2014 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p3JPN_ObgYA for ; Fri, 6 Jun 2014 09:10:13 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C051A018B for ; Fri, 6 Jun 2014 09:10:05 -0700 (PDT) Received: from [109.144.193.128] (helo=[10.210.198.148]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WswiH-0006pf-3Z; Fri, 06 Jun 2014 17:09:53 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_436CA01E-7355-44BC-A222-08141BD25644" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rob Shakir In-Reply-To: <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> Date: Fri, 6 Jun 2014 17:09:53 +0100 Message-Id: References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> To: Pierre Francois X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/6F5u_5yRm8hbprfVcVNP3oDkElo Cc: "spring@ietf.org" , Anoop Ghanwani Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 16:10:16 -0000 --Apple-Mail=_436CA01E-7355-44BC-A222-08141BD25644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Anoop, As Pierre says, the head-end is able to choose whether he would like = protection from a midpoint. This assumes that one advertises both = =93protected=94 and =93unprotected=94 segments within a network where = there may be a requirement for both, allowing the head-end to select the = relevant segment. This is roughly analogous to the behaviour of = requesting FRR (or not) when signalling a TE-LSP, and hence has the same = security characteristics from my perspective. It should be noted that _if_ all segments are advertised as protected = (and non-revertive/unprotected segments are not available) then this may = introduce more detailed per-LSP OAM requirements at the head-end to = ensure that it can react to a service which does not meet its = performance constraints during a period where local FRR is being = utilised by a midpoint on the path. Kind regards, r. On 6 Jun 2014, at 15:53, Pierre Francois = wrote: >=20 >=20 > Anoop,=20 >=20 > Well, we have this requirement to be able to have both approaches = doable at the same time on the same network...=20 >=20 > For example, in SR, you can encode configure your segments as to be = protected, or not.=20 >=20 > If you want local protection, configure segments to be locally = protected.=20 > If you want path protection, configure segments to not be locally = protected.=20 >=20 > If you need both for two different services, you'd configure both = types and pick the ones that match the service you need.=20 >=20 > Cheers,=20 >=20 > Pierre. >=20 >=20 >=20 > On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani = wrote: >=20 >> Pierre, >>=20 >> My question is more from a security standpoint. >>=20 >> If a node is explicitly identified in the path and that node is down, = is it OK to route around it. >>=20 >> I guess what I'm hearing you say is that it depends on what the = network operator has configured. They can choose to either discard all = such packets, or route all such packets around the failure, but they = cannot choose what it to be done on a per-packet basis. Do I have that = right? >>=20 >> Anoop >>=20 >>=20 >> On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois = wrote: >>=20 >> Anoop,=20 >>=20 >> You loose the traffic until the moment the ingress node falls back on = another path.=20 >>=20 >> If you don't want to have to wait for that failover to happen, then = your use-case is in another section than the one using path protection = ;) >>=20 >> Pierre. >>=20 >>=20 >>=20 >> On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani = wrote: >>=20 >>> Thanks Pierre. >>>=20 >>> What if the failed component is one of the explicitly identified = hops? >>>=20 >>> Anoop >>>=20 >>>=20 >>> On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = wrote: >>>=20 >>> Hello Anoop,=20 >>>=20 >>> In path protection, section 2, the packets will be dropped until the = ingress node decides to stop using the failed path and failover.=20 >>>=20 >>> In all other sections, the packets are to be rerouted directly by = the nodes adjacent to the failed component. >>>=20 >>> Cheers,=20 >>>=20 >>> Pierre. >>>=20 >>> On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani = wrote: >>>=20 >>>> I have a question about this draft. >>>>=20 >>>> In section 2, it has the following statement: >>>> >>> >>>> >=46rom a SPRING viewpoint, we would like to highlight the = following >>>> requirement: the two configured paths T1 and T2 MUST NOT benefit = from >>>> local protection. >>>> >>> >>>>=20 >>>> But there is no such statement in subsequent sections. >>>>=20 >>>> So suppose I have a data packet using SPRING to use path A - B - C. = If B is down, would such packets be discarded or would there be an = attempt to get it to C if one of the other methods for repair is = configured? >>>>=20 >>>> Anoop >>>>=20 >>>> On Tue, May 13, 2014 at 9:35 AM, wrote: >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the Source Packet Routing in = Networking Working Group of the IETF. >>>>=20 >>>> Title : Use-cases for Resiliency in SPRING >>>> Authors : Pierre Francois >>>> Clarence Filsfils >>>> Bruno Decraene >>>> Rob Shakir >>>> Filename : = draft-ietf-spring-resiliency-use-cases-00.txt >>>> Pages : 8 >>>> Date : 2014-05-12 >>>>=20 >>>> Abstract: >>>> This document describes the use cases for resiliency in SPRING >>>> networks. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> = https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >>>>=20 >>>> There's also a htmlized version available at: >>>> = http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>>=20 >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>=20 >>>=20 >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>=20 >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_436CA01E-7355-44BC-A222-08141BD25644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Anoop,

As Pierre says, the = head-end is able to choose whether he would like protection from a = midpoint. This assumes that one advertises both =93protected=94 and = =93unprotected=94 segments within a network where there may be a = requirement for both, allowing the head-end to select the relevant = segment. This is roughly analogous to the behaviour of requesting FRR = (or not) when signalling a TE-LSP, and hence has the same security = characteristics from my perspective.

It should = be noted that _if_ all segments are advertised as protected (and = non-revertive/unprotected segments are not available) then this may = introduce more detailed per-LSP OAM requirements at the head-end to = ensure that it can react to a service which does not meet its = performance constraints during a period where local FRR is being = utilised by a midpoint on the path.

Kind = regards,
r.




On 6 Jun 2014, at 15:53, Pierre Francois <pierre.francois@imdea.org>= ; wrote:

anoop@alumni.duke.edu> = wrote:

Pierre,

My question is = more from a security standpoint.

If a node is = explicitly identified in the path and that node is down, is it OK to = route around it.

I guess what I'm hearing you say is that it depends on = what the network operator has configured.  They can choose to = either discard all such packets, or route all such packets around the = failure, but they cannot choose what it to be done on a per-packet = basis.  Do I have that right?

Anoop


On Fri, Jun 6, = 2014 at 7:38 AM, Pierre Francois <pierre.francois@imdea.org> wrote:

Anoop, 
=
You loose the traffic until the moment the ingress node falls = back on another path. 

If you don't want to have to wait for that failover to = happen, then your use-case is in another section than the one using path = protection ;)

Pierre.



On Jun 6, 2014, at = 4:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Thanks = Pierre.

What if the failed component is one of the = explicitly identified = hops?

Anoop


On Fri, Jun 6, 2014 at 5:28 AM, Pierre = Francois <pierre.francois@imdea.org> wrote:

Hello = Anoop, 

In path protection, section 2, the = packets will be dropped until the ingress node decides to stop using the = failed path and failover. 

In all other sections, the packets are to be = rerouted directly by the nodes adjacent to the failed = component.

Cheers, 

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> = wrote:

I have a = question about this draft.

In section 2, it has the following = statement:
>>>
>=46rom a =
SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local =
protection.
>>>

But there is no such statement in subsequent = sections.

So suppose I have a data packet using SPRING to = use path A - B - C.  If B is down, would such packets be discarded = or would there be an attempt to get it to C if one of the other methods = for repair is configured?

Anoop

On Tue, = May 13, 2014 at 9:35 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Source Packet Routing in = Networking Working Group of the IETF.

        Title           : = Use-cases for Resiliency in SPRING
        Authors         : Pierre = Francois
                    =       Clarence Filsfils
                    =       Bruno Decraene
                    =       Rob Shakir
        Filename        : = draft-ietf-spring-resiliency-use-cases-00.txt
        Pages           : = 8
        Date           =  : 2014-05-12

Abstract:
   This document describes the use cases for resiliency in = SPRING
   networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-resil= iency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resiliency-= use-cases-00


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
=


_______________________________________________
spring mailing = list
spring@ietf.org
https://www.ietf.org= /mailman/listinfo/spring

_______= ________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.or= g/mailman/listinfo/spring

= --Apple-Mail=_436CA01E-7355-44BC-A222-08141BD25644-- From nobody Fri Jun 6 09:41:31 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F491A00F9 for ; Fri, 6 Jun 2014 09:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzl6M-C_8yv5 for ; Fri, 6 Jun 2014 09:41:23 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E46A1A0115 for ; Fri, 6 Jun 2014 09:41:23 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so3107953wev.19 for ; Fri, 06 Jun 2014 09:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sh72eh8U74+P7YRWP9mJA27kRgJW/N6+c9BiWmv2Vq0=; b=k6T5JYRj/nOUWPirck826tPQS566rNB0scepAHmwww9HiDtCb9uK6W6IRMZqmC5ulz eqiXu+5eD0PV05OtQpc9k0FyBdWr/o5nCY+fAr5m256k7ANbA6HP8gSaOYpGuna/NdXd fKl94GOpsj9WCThlDKbSLAd0ksMmilDq9311Vs7Q2QSpdUV1mBGfH1Vbk9IlfBMtOwul 3Dj3yo/qY5/4jknk9NZpzZtdn/ovgOc7W7/t2JqqrOVJ6TOOY6nTemP6mrJlWUPzedd4 Lze7uI4sUxaeSn0ApGlouHg52A9SEAhcO9fNwfpgs3trScyEy73AwMX+4G342gb1szTk yoKw== MIME-Version: 1.0 X-Received: by 10.194.77.2 with SMTP id o2mr8765492wjw.68.1402072875278; Fri, 06 Jun 2014 09:41:15 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.182.67 with HTTP; Fri, 6 Jun 2014 09:41:15 -0700 (PDT) In-Reply-To: References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> Date: Fri, 6 Jun 2014 09:41:15 -0700 X-Google-Sender-Auth: Eg9W_R7sa7eQJXU3FwFYcjRabQA Message-ID: From: Anoop Ghanwani To: Rob Shakir Content-Type: multipart/alternative; boundary=047d7bfced9cae288904fb2d87eb Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Hwwjjcw-bOJHnERM6FhwvdqIw40 Cc: Pierre Francois , "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 16:41:27 -0000 --047d7bfced9cae288904fb2d87eb Content-Type: text/plain; charset=ISO-8859-1 Pierre and Rob, Thanks for the clarification. I guess I was expecting to see some of that discussion in the draft, but perhaps that is covered elsewhere. Anoop On Fri, Jun 6, 2014 at 9:09 AM, Rob Shakir wrote: > Anoop, > > As Pierre says, the head-end is able to choose whether he would like > protection from a midpoint. This assumes that one advertises both > "protected" and "unprotected" segments within a network where there may be > a requirement for both, allowing the head-end to select the relevant > segment. This is roughly analogous to the behaviour of requesting FRR (or > not) when signalling a TE-LSP, and hence has the same security > characteristics from my perspective. > > It should be noted that _if_ all segments are advertised as protected (and > non-revertive/unprotected segments are not available) then this may > introduce more detailed per-LSP OAM requirements at the head-end to ensure > that it can react to a service which does not meet its performance > constraints during a period where local FRR is being utilised by a midpoint > on the path. > > Kind regards, > r. > > > > > On 6 Jun 2014, at 15:53, Pierre Francois > wrote: > > > > Anoop, > > Well, we have this requirement to be able to have both approaches doable > at the same time on the same network... > > For example, in SR, you can encode configure your segments as to be > protected, or not. > > If you want local protection, configure segments to be locally protected. > If you want path protection, configure segments to not be locally > protected. > > If you need both for two different services, you'd configure both types > and pick the ones that match the service you need. > > Cheers, > > Pierre. > > > > On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani wrote: > > Pierre, > > My question is more from a security standpoint. > > If a node is explicitly identified in the path and that node is down, is > it OK to route around it. > > I guess what I'm hearing you say is that it depends on what the network > operator has configured. They can choose to either discard all such > packets, or route all such packets around the failure, but they cannot > choose what it to be done on a per-packet basis. Do I have that right? > > Anoop > > > On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois > wrote: > >> >> Anoop, >> >> You loose the traffic until the moment the ingress node falls back on >> another path. >> >> If you don't want to have to wait for that failover to happen, then your >> use-case is in another section than the one using path protection ;) >> >> Pierre. >> >> >> >> On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani wrote: >> >> Thanks Pierre. >> >> What if the failed component is one of the explicitly identified hops? >> >> Anoop >> >> >> On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois < >> pierre.francois@imdea.org> wrote: >> >>> >>> Hello Anoop, >>> >>> In path protection, section 2, the packets will be dropped until the >>> ingress node decides to stop using the failed path and failover. >>> >>> In all other sections, the packets are to be rerouted directly by the >>> nodes adjacent to the failed component. >>> >>> Cheers, >>> >>> Pierre. >>> >>> On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani >>> wrote: >>> >>> I have a question about this draft. >>> >>> In section 2, it has the following statement: >>> >>> >>> >>> >From a SPRING viewpoint, we would like to highlight the following >>> requirement: the two configured paths T1 and T2 MUST NOT benefit from >>> local protection. >>> >>> >>> >>> >>> But there is no such statement in subsequent sections. >>> >>> So suppose I have a data packet using SPRING to use path A - B - C. If >>> B is down, would such packets be discarded or would there be an attempt to >>> get it to C if one of the other methods for repair is configured? >>> >>> Anoop >>> >>> On Tue, May 13, 2014 at 9:35 AM, wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Source Packet Routing in Networking >>>> Working Group of the IETF. >>>> >>>> Title : Use-cases for Resiliency in SPRING >>>> Authors : Pierre Francois >>>> Clarence Filsfils >>>> Bruno Decraene >>>> Rob Shakir >>>> Filename : draft-ietf-spring-resiliency-use-cases-00.txt >>>> Pages : 8 >>>> Date : 2014-05-12 >>>> >>>> Abstract: >>>> This document describes the use cases for resiliency in SPRING >>>> networks. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>> >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> >>> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --047d7bfced9cae288904fb2d87eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Pierre and Rob,

Thanks for the clarific= ation.

I guess I was expecting to see some of that d= iscussion in the draft, but perhaps that is covered elsewhere.
Anoop


On Fri, Jun 6, 2014 at 9:09 AM, Rob Shakir <<= a href=3D"mailto:rjs@rob.sh" target=3D"_blank">rjs@rob.sh> wr= ote:
Anoop,
As Pierre says, the head-end is able to choose whether he= would like protection from a midpoint. This assumes that one advertises bo= th “protected” and “unprotected” segments within a = network where there may be a requirement for both, allowing the head-end to= select the relevant segment. This is roughly analogous to the behaviour of= requesting FRR (or not) when signalling a TE-LSP, and hence has the same s= ecurity characteristics from my perspective.

It should be noted that _if_ all segments are advertise= d as protected (and non-revertive/unprotected segments are not available) t= hen this may introduce more detailed per-LSP OAM requirements at the head-e= nd to ensure that it can react to a service which does not meet its perform= ance constraints during a period where local FRR is being utilised by a mid= point on the path.

Kind regards,
r.
=




On 6 J= un 2014, at 15:53, Pierre Francois <pierre.francois@imdea.org> wrote:


=

Anoop, 

Well, we have this req= uirement to be able to have both approaches doable at the same time on the = same network... 

For example, in SR, you can encode configure your segme= nts as to be protected, or not. 

If you want = local protection, configure segments to be locally protected. 
If you want path protection, configure segments to not be locally protec= ted. 

If you need both for two different services, you'd = configure both types and pick the ones that match the service you need.&nbs= p;

Cheers, 

Pierre.<= /div>



On Jun 6, 2014, at 4:45 PM, Ano= op Ghanwani <= anoop@alumni.duke.edu> wrote:

Pierre,

My question is more from a security standpoint.<= /div>

If a node is explicitly identified in the path and= that node is down, is it OK to route around it.

I guess what I'm hearing you say is that it depends on w= hat the network operator has configured.  They can choose to either di= scard all such packets, or route all such packets around the failure, but t= hey cannot choose what it to be done on a per-packet basis.  Do I have= that right?

Anoop


On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <pierre.francois@imdea.org> wrote:
Anoop, 

You loose the traffic until th= e moment the ingress node falls back on another path. 

If you don't want to have to wait for that failover to h= appen, then your use-case is in another section than the one using path pro= tection ;)

Pierre.
=



On Jun 6, 2014, at 4:30 PM, Anoo= p Ghanwani <a= noop@alumni.duke.edu> wrote:

Thanks Pierre.

What if the failed component is one of the explicitly identified hops= ?

Anoop

=
On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = <pierre.francois@imdea.org> wrote:
Hello Anoop, 

In path protection, section 2,= the packets will be dropped until the ingress node decides to stop using t= he failed path and failover. 

In all other sections, the packets are to be rerouted d= irectly by the nodes adjacent to the failed component.

=
Cheers, 

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
I have a question about this d= raft.

In section 2, it has the following statement:
>= >>
>From a SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local protection.
>>>

But there is no such statement in subsequent sectio= ns.

So= suppose I have a data packet using SPRING to use path A - B - C.  If = B is down, would such packets be discarded or would there be an attempt to = get it to C if one of the other methods for repair is configured?

Anoop
On Tue, May 13, 2014 at 9:35 AM, <int= ernet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF.

        Title           : Use-= cases for Resiliency in SPRING
        Authors         : Pierre Fr= ancois
                     = ;     Clarence Filsfils
                     = ;     Bruno Decraene
                     = ;     Rob Shakir
        Filename        : draft-iet= f-spring-resiliency-use-cases-00.txt
        Pages           : 8         Date            := 2014-05-12

Abstract:
   This document describes the use cases for resiliency in SPRING=
   networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spr= ing-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resili= ency-use-cases-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring

________________________________________= _______
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/sp= ring

--047d7bfced9cae288904fb2d87eb-- From nobody Fri Jun 6 09:51:31 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7DF1A01BF for ; Fri, 6 Jun 2014 09:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glTBt7_SC2gk for ; Fri, 6 Jun 2014 09:51:19 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5DC1A01B3 for ; Fri, 6 Jun 2014 09:51:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 261661B7A08; Fri, 6 Jun 2014 18:50:50 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjYkXboaVhuB; Fri, 6 Jun 2014 18:50:49 +0200 (CEST) Received: from [10.112.235.92] (233.Red-176-83-37.dynamicIP.rima-tde.net [176.83.37.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id B7FB41B7A07; Fri, 6 Jun 2014 18:50:49 +0200 (CEST) References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-886AE2CD-7326-45A1-87B8-A3D4CAF251B1 Content-Transfer-Encoding: 7bit Message-Id: <80A501AD-B68B-4DCF-BC91-997035B995D0@imdea.org> X-Mailer: iPhone Mail (11B651) From: Pierre Francois Date: Fri, 6 Jun 2014 18:51:10 +0200 To: Anoop Ghanwani Archived-At: http://mailarchive.ietf.org/arch/msg/spring/2mAknVey9ERgT9qHHR-AT3kontU Cc: "spring@ietf.org" , Rob Shakir Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 16:51:27 -0000 --Apple-Mail-886AE2CD-7326-45A1-87B8-A3D4CAF251B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Anoop, If this was unclear, I'll try to make the point better in next revision. Regards, Pierre. Sent from my iPhone > On Jun 6, 2014, at 6:41 PM, Anoop Ghanwani wrote: >=20 > Pierre and Rob, >=20 > Thanks for the clarification. >=20 > I guess I was expecting to see some of that discussion in the draft, but p= erhaps that is covered elsewhere. >=20 > Anoop >=20 >=20 >> On Fri, Jun 6, 2014 at 9:09 AM, Rob Shakir wrote: >> Anoop, >>=20 >> As Pierre says, the head-end is able to choose whether he would like prot= ection from a midpoint. This assumes that one advertises both =E2=80=9Cprote= cted=E2=80=9D and =E2=80=9Cunprotected=E2=80=9D segments within a network wh= ere there may be a requirement for both, allowing the head-end to select the= relevant segment. This is roughly analogous to the behaviour of requesting = FRR (or not) when signalling a TE-LSP, and hence has the same security chara= cteristics from my perspective. >>=20 >> It should be noted that _if_ all segments are advertised as protected (an= d non-revertive/unprotected segments are not available) then this may introd= uce more detailed per-LSP OAM requirements at the head-end to ensure that it= can react to a service which does not meet its performance constraints duri= ng a period where local FRR is being utilised by a midpoint on the path. >>=20 >> Kind regards, >> r. >>=20 >>=20 >>=20 >>=20 >>> On 6 Jun 2014, at 15:53, Pierre Francois wro= te: >>>=20 >>>=20 >>>=20 >>> Anoop,=20 >>>=20 >>> Well, we have this requirement to be able to have both approaches doable= at the same time on the same network...=20 >>>=20 >>> For example, in SR, you can encode configure your segments as to be prot= ected, or not.=20 >>>=20 >>> If you want local protection, configure segments to be locally protected= .=20 >>> If you want path protection, configure segments to not be locally protec= ted.=20 >>>=20 >>> If you need both for two different services, you'd configure both types a= nd pick the ones that match the service you need.=20 >>>=20 >>> Cheers,=20 >>>=20 >>> Pierre. >>>=20 >>>=20 >>>=20 >>>> On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani wrot= e: >>>>=20 >>>> Pierre, >>>>=20 >>>> My question is more from a security standpoint. >>>>=20 >>>> If a node is explicitly identified in the path and that node is down, i= s it OK to route around it. >>>>=20 >>>> I guess what I'm hearing you say is that it depends on what the network= operator has configured. They can choose to either discard all such packet= s, or route all such packets around the failure, but they cannot choose what= it to be done on a per-packet basis. Do I have that right? >>>>=20 >>>> Anoop >>>>=20 >>>>=20 >>>>> On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois wrote: >>>>>=20 >>>>> Anoop,=20 >>>>>=20 >>>>> You loose the traffic until the moment the ingress node falls back on a= nother path.=20 >>>>>=20 >>>>> If you don't want to have to wait for that failover to happen, then yo= ur use-case is in another section than the one using path protection ;) >>>>>=20 >>>>> Pierre. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani wr= ote: >>>>>>=20 >>>>>> Thanks Pierre. >>>>>>=20 >>>>>> What if the failed component is one of the explicitly identified hops= ? >>>>>>=20 >>>>>> Anoop >>>>>>=20 >>>>>>=20 >>>>>>> On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois wrote: >>>>>>>=20 >>>>>>> Hello Anoop,=20 >>>>>>>=20 >>>>>>> In path protection, section 2, the packets will be dropped until the= ingress node decides to stop using the failed path and failover.=20 >>>>>>>=20 >>>>>>> In all other sections, the packets are to be rerouted directly by th= e nodes adjacent to the failed component. >>>>>>>=20 >>>>>>> Cheers,=20 >>>>>>>=20 >>>>>>> Pierre. >>>>>>>=20 >>>>>>>> On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani w= rote: >>>>>>>>=20 >>>>>>>> I have a question about this draft. >>>>>>>>=20 >>>>>>>> In section 2, it has the following statement: >>>>>>>> >>> >>>>>>>> >=46rom a SPRING viewpoint, we would like to highlight the followin= g >>>>>>>> requirement: the two configured paths T1 and T2 MUST NOT benefit fr= om >>>>>>>> local protection. >>>>>>>> >>> >>>>>>>>=20 >>>>>>>> But there is no such statement in subsequent sections. >>>>>>>>=20 >>>>>>>> So suppose I have a data packet using SPRING to use path A - B - C.= If B is down, would such packets be discarded or would there be an attempt= to get it to C if one of the other methods for repair is configured? >>>>>>>>=20 >>>>>>>> Anoop >>>>>>>>=20 >>>>>>>>> On Tue, May 13, 2014 at 9:35 AM, wrote:= >>>>>>>>>=20 >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts= directories. >>>>>>>>> This draft is a work item of the Source Packet Routing in Network= ing Working Group of the IETF. >>>>>>>>>=20 >>>>>>>>> Title : Use-cases for Resiliency in SPRING >>>>>>>>> Authors : Pierre Francois >>>>>>>>> Clarence Filsfils >>>>>>>>> Bruno Decraene >>>>>>>>> Rob Shakir >>>>>>>>> Filename : draft-ietf-spring-resiliency-use-cases-0= 0.txt >>>>>>>>> Pages : 8 >>>>>>>>> Date : 2014-05-12 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> This document describes the use cases for resiliency in SPRING >>>>>>>>> networks. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-= cases/ >>>>>>>>>=20 >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-= 00 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Please note that it may take a couple of minutes from the time of s= ubmission >>>>>>>>> until the htmlized version and diff are available at tools.ietf.or= g. >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> spring mailing list >>>>>>>>> spring@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> spring mailing list >>>>>>>> spring@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>>=20 >>>>>> _______________________________________________ >>>>>> spring mailing list >>>>>> spring@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>=20 >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>=20 >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail-886AE2CD-7326-45A1-87B8-A3D4CAF251B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Anoop,

If this was unclear, I'll try to make the point better in next revi= sion.

Regards,

Pierre.
=
Sent from my iPhone

On Jun 6, 2014, at 6:41 PM, Anoop Ghan= wani <anoop@alumni.duke.edu&= gt; wrote:

Pier= re and Rob,

Thanks for the clarification.

I guess I was expecting to see some of that discussion in the draft,= but perhaps that is covered elsewhere.

Anoop


On Fri, Jun 6, 2014 at 9:09 AM, Rob Shakir <rjs@rob.sh> wrote:=
Anoop,
As Pierre says, the head-end is able to choose whether he wo= uld like protection from a midpoint. This assumes that one advertises both =E2= =80=9Cprotected=E2=80=9D and =E2=80=9Cunprotected=E2=80=9D segments within a= network where there may be a requirement for both, allowing the head-end to= select the relevant segment. This is roughly analogous to the behaviour of r= equesting FRR (or not) when signalling a TE-LSP, and hence has the same secu= rity characteristics from my perspective.

It should be noted that _if_ all segments are advertised= as protected (and non-revertive/unprotected segments are not available) the= n this may introduce more detailed per-LSP OAM requirements at the head-end t= o ensure that it can react to a service which does not meet its performance c= onstraints during a period where local FRR is being utilised by a midpoint o= n the path.

Kind regards,
r.
<= div>



On 6 Jun= 2014, at 15:53, Pierre Francois <pierre.francois@imdea.org> wrote:


<= /div>

Anoop, 

Well, we have this requi= rement to be able to have both approaches doable at the same time on the sam= e network... 

For example, in SR, you can encode configure your segmen= ts as to be protected, or not. 

If you want lo= cal protection, configure segments to be locally protected. 
= If you want path protection, configure segments to not be locally protected.=  

If you need both for two different services, you'd confi= gure both types and pick the ones that match the service you need. 

Cheers, 

Pierre.



On Jun 6, 2014, at 4:45 PM, Anoo= p Ghanwani <an= oop@alumni.duke.edu> wrote:

Pierre,

My question is more from a security standpoint.

If a node is explicitly identified in the path and t= hat node is down, is it OK to route around it.

I guess what I'm hearing you say is that it depends on what t= he network operator has configured.  They can choose to either discard a= ll such packets, or route all such packets around the failure, but they cann= ot choose what it to be done on a per-packet basis.  Do I have that rig= ht?

Anoop


On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <pierre.francois@imdea.org> wrote:

<= /div>
Anoop, 

You loose the traffic until the m= oment the ingress node falls back on another path. 

If you don't want to have to wait for that failover to happen= , then your use-case is in another section than the one using path protectio= n ;)

Pierre.
<= div>


On Jun 6, 2014, at 4:30 PM, Anoop G= hanwani <anoop= @alumni.duke.edu> wrote:

Thanks Pierre.

=
What if the failed component is one of the explicitly identified hops?<= /div>

Anoop

On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <= span dir=3D"ltr"><pierre.francois@imdea.org> wrote:

<= /div>Hello Anoop, 

In path protection, section 2, th= e packets will be dropped until the ingress node decides to stop using the f= ailed path and failover. 

In all other sections, the packets are to be rerouted di= rectly by the nodes adjacent to the failed component.

Cheers, 

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

=
I have a question about this draf= t.

In section 2, it has the following statement:
>&= gt;>
>=46rom a SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local protection.
>>>

But there is no such statement in subsequent sections= .

So su= ppose I have a data packet using SPRING to use path A - B - C.  If B is= down, would such packets be discarded or would there be an attempt to get i= t to C if one of the other methods for repair is configured?

Anoop
On Tue, May 13, 2014 at 9:35 AM, <intern= et-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directori= es.
 This draft is a work item of the Source Packet Routing in Networking W= orking Group of the IETF.

        Title           : Use-c= ases for Resiliency in SPRING
        Authors         : Pierre Fra= ncois
                     =     Clarence Filsfils
                     =     Bruno Decraene
                     =     Rob Shakir
        Filename        : draft-ietf= -spring-resiliency-use-cases-00.txt
        Pages           : 8
=         Date            : 2= 014-05-12

Abstract:
   This document describes the use cases for resiliency in SPRING<= br>    networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sprin= g-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resilien= cy-use-cases-00


Please note that it may take a couple of minutes from the time of submission=
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.= ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
spring@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
spring@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
spring@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/spring

_________________________________________= ______
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring<= /a>


=
____________________= ___________________________
spring mailing list
spring@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/spring">https://www.ietf.org= /mailman/listinfo/spring
= --Apple-Mail-886AE2CD-7326-45A1-87B8-A3D4CAF251B1-- From nobody Fri Jun 6 10:40:53 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FAB1A01D9 for ; Fri, 6 Jun 2014 10:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5cB_ClBMPDz for ; Fri, 6 Jun 2014 10:40:46 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CC81A01D8 for ; Fri, 6 Jun 2014 10:40:45 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so3082219wgh.26 for ; Fri, 06 Jun 2014 10:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YshSfkknGfiFQQCBDFpgYLIFrfZ0jhsX2uKG5jaBs50=; b=rP59rGe1Xk4K5N6jtKGHzpXdvH1Oo0bVFJC6ckTOXcxESj2AcvUPKh2JcT319hDF+e 0ZSUH5v0cIZJtIPCXd0Bbscdrc/51hSTZmDyqXYvaXc4c5Pq+db2FxEuKdK1AH2SRoWp xBa9Fet/AEHBSkxvMnFfmnyvWdE3u7xupRvqT/CY7eD3/Q5YOYCDhX2ho7bmoFZMNnNs QFouCiIFTCeqIa/F0IIp5A/QyJIia5B5wSPo/fvgFcuqiHPHq/xftdpN8NaC7F+F3T0a hMertWWF4Z5XnSuFTr8ee2vefIr7vp6D8tUdzsOinHJ7XjXSeql4Wf0xDg8p4oZIEMbX 4JAw== MIME-Version: 1.0 X-Received: by 10.194.63.196 with SMTP id i4mr9341745wjs.50.1402076438104; Fri, 06 Jun 2014 10:40:38 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.182.67 with HTTP; Fri, 6 Jun 2014 10:40:38 -0700 (PDT) In-Reply-To: <80A501AD-B68B-4DCF-BC91-997035B995D0@imdea.org> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> <80A501AD-B68B-4DCF-BC91-997035B995D0@imdea.org> Date: Fri, 6 Jun 2014 10:40:38 -0700 X-Google-Sender-Auth: LfcpKIzNjlOyA0jNVh4wucD7eHA Message-ID: From: Anoop Ghanwani To: Pierre Francois Content-Type: multipart/alternative; boundary=047d7b86dd000a918d04fb2e5c17 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/i6-fVgwzDojO4tzUVBW9IRJDPGU Cc: "spring@ietf.org" , Rob Shakir Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 17:40:50 -0000 --047d7b86dd000a918d04fb2e5c17 Content-Type: text/plain; charset=ISO-8859-1 Pierre, Re-reading the doc, it sounds like this is covered by the 5th bullet in Section 5. Thanks, Anoop On Fri, Jun 6, 2014 at 9:51 AM, Pierre Francois wrote: > > Anoop, > > If this was unclear, I'll try to make the point better in next revision. > > Regards, > > Pierre. > > Sent from my iPhone > > On Jun 6, 2014, at 6:41 PM, Anoop Ghanwani wrote: > > Pierre and Rob, > > Thanks for the clarification. > > I guess I was expecting to see some of that discussion in the draft, but > perhaps that is covered elsewhere. > > Anoop > > > On Fri, Jun 6, 2014 at 9:09 AM, Rob Shakir wrote: > >> Anoop, >> >> As Pierre says, the head-end is able to choose whether he would like >> protection from a midpoint. This assumes that one advertises both >> "protected" and "unprotected" segments within a network where there may be >> a requirement for both, allowing the head-end to select the relevant >> segment. This is roughly analogous to the behaviour of requesting FRR (or >> not) when signalling a TE-LSP, and hence has the same security >> characteristics from my perspective. >> >> It should be noted that _if_ all segments are advertised as protected >> (and non-revertive/unprotected segments are not available) then this may >> introduce more detailed per-LSP OAM requirements at the head-end to ensure >> that it can react to a service which does not meet its performance >> constraints during a period where local FRR is being utilised by a midpoint >> on the path. >> >> Kind regards, >> r. >> >> >> >> >> On 6 Jun 2014, at 15:53, Pierre Francois >> wrote: >> >> >> >> Anoop, >> >> Well, we have this requirement to be able to have both approaches doable >> at the same time on the same network... >> >> For example, in SR, you can encode configure your segments as to be >> protected, or not. >> >> If you want local protection, configure segments to be locally protected. >> If you want path protection, configure segments to not be locally >> protected. >> >> If you need both for two different services, you'd configure both types >> and pick the ones that match the service you need. >> >> Cheers, >> >> Pierre. >> >> >> >> On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani wrote: >> >> Pierre, >> >> My question is more from a security standpoint. >> >> If a node is explicitly identified in the path and that node is down, is >> it OK to route around it. >> >> I guess what I'm hearing you say is that it depends on what the network >> operator has configured. They can choose to either discard all such >> packets, or route all such packets around the failure, but they cannot >> choose what it to be done on a per-packet basis. Do I have that right? >> >> Anoop >> >> >> On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois < >> pierre.francois@imdea.org> wrote: >> >>> >>> Anoop, >>> >>> You loose the traffic until the moment the ingress node falls back on >>> another path. >>> >>> If you don't want to have to wait for that failover to happen, then your >>> use-case is in another section than the one using path protection ;) >>> >>> Pierre. >>> >>> >>> >>> On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani >>> wrote: >>> >>> Thanks Pierre. >>> >>> What if the failed component is one of the explicitly identified hops? >>> >>> Anoop >>> >>> >>> On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois < >>> pierre.francois@imdea.org> wrote: >>> >>>> >>>> Hello Anoop, >>>> >>>> In path protection, section 2, the packets will be dropped until the >>>> ingress node decides to stop using the failed path and failover. >>>> >>>> In all other sections, the packets are to be rerouted directly by the >>>> nodes adjacent to the failed component. >>>> >>>> Cheers, >>>> >>>> Pierre. >>>> >>>> On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani >>>> wrote: >>>> >>>> I have a question about this draft. >>>> >>>> In section 2, it has the following statement: >>>> >>> >>>> >>>> >From a SPRING viewpoint, we would like to highlight the following >>>> requirement: the two configured paths T1 and T2 MUST NOT benefit from >>>> local protection. >>>> >>>> >>> >>>> >>>> But there is no such statement in subsequent sections. >>>> >>>> So suppose I have a data packet using SPRING to use path A - B - C. If >>>> B is down, would such packets be discarded or would there be an attempt to >>>> get it to C if one of the other methods for repair is configured? >>>> >>>> Anoop >>>> >>>> On Tue, May 13, 2014 at 9:35 AM, wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Source Packet Routing in Networking >>>>> Working Group of the IETF. >>>>> >>>>> Title : Use-cases for Resiliency in SPRING >>>>> Authors : Pierre Francois >>>>> Clarence Filsfils >>>>> Bruno Decraene >>>>> Rob Shakir >>>>> Filename : draft-ietf-spring-resiliency-use-cases-00.txt >>>>> Pages : 8 >>>>> Date : 2014-05-12 >>>>> >>>>> Abstract: >>>>> This document describes the use cases for resiliency in SPRING >>>>> networks. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> spring mailing list >>>>> spring@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spring >>>>> >>>> >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>> >>>> >>>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> >>> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --047d7b86dd000a918d04fb2e5c17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Pierre,

Re-reading the doc, it sounds l= ike this is covered by the 5th bullet in Section 5.

Thanks,
Anoop


On Fri, Jun 6, 2014 at 9:51 AM, Pierre Francois <pierre.francois@i= mdea.org> wrote:

Anoop,

If th= is was unclear, I'll try to make the point better in next revision.

Regards,

Pierre.

Sent= from my iPhone

On Jun 6, 2014, at 6:41 PM, Anoop Ghanwani = <anoop@alumni= .duke.edu> wrote:

Pierre and Rob,

Thanks for the clarification.
I guess I was expecting to see some of that discussion in the = draft, but perhaps that is covered elsewhere.

Anoop


On Fri, Jun 6, 2014 at 9:09 AM, Rob Shakir <<= a href=3D"mailto:rjs@rob.sh" target=3D"_blank">rjs@rob.sh> wr= ote:
Anoop,
As Pierre says, the head-end is able to choose whether he= would like protection from a midpoint. This assumes that one advertises bo= th “protected” and “unprotected” segments within a = network where there may be a requirement for both, allowing the head-end to= select the relevant segment. This is roughly analogous to the behaviour of= requesting FRR (or not) when signalling a TE-LSP, and hence has the same s= ecurity characteristics from my perspective.

It should be noted that _if_ all segments are advertise= d as protected (and non-revertive/unprotected segments are not available) t= hen this may introduce more detailed per-LSP OAM requirements at the head-e= nd to ensure that it can react to a service which does not meet its perform= ance constraints during a period where local FRR is being utilised by a mid= point on the path.

Kind regards,
r.




On 6 Jun 2014, at 1= 5:53, Pierre Francois <pierre.francois@imdea.org> wrote:


=

Anoop, 

Well, we have this req= uirement to be able to have both approaches doable at the same time on the = same network... 

For example, in SR, you can encode configure your segme= nts as to be protected, or not. 

If you want = local protection, configure segments to be locally protected. 
If you want path protection, configure segments to not be locally protec= ted. 

If you need both for two different services, you'd = configure both types and pick the ones that match the service you need.&nbs= p;

Cheers, 

Pierre.<= /div>



On Jun 6, 2014, at 4:45 PM, Ano= op Ghanwani <= anoop@alumni.duke.edu> wrote:

Pierre,

My question is more from a security standpoint.<= /div>

If a node is explicitly identified in the path and= that node is down, is it OK to route around it.

I guess what I'm hearing you say is that it depends on w= hat the network operator has configured.  They can choose to either di= scard all such packets, or route all such packets around the failure, but t= hey cannot choose what it to be done on a per-packet basis.  Do I have= that right?

Anoop


On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <pierre.francois@imdea.org> wrote:
Anoop, 

You loose the traffic until th= e moment the ingress node falls back on another path. 

If you don't want to have to wait for that failover to h= appen, then your use-case is in another section than the one using path pro= tection ;)

Pierre.
=



On Jun 6, 2014, at 4:30 PM, Anoo= p Ghanwani <a= noop@alumni.duke.edu> wrote:

Thanks Pierre.

What if the failed component is one of the explicitly identified hops= ?

Anoop

=
On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = <pierre.francois@imdea.org> wrote:
Hello Anoop, 

In path protection, section 2,= the packets will be dropped until the ingress node decides to stop using t= he failed path and failover. 

In all other sections, the packets are to be rerouted d= irectly by the nodes adjacent to the failed component.

=
Cheers, 

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
I have a question about this d= raft.

In section 2, it has the following statement:
>= >>
>From a SPRING viewpoint, we would like to highlight the following
requirement: the two configured paths T1 and T2 MUST NOT benefit from
local protection.
>>>

But there is no such statement in subsequent sectio= ns.

So= suppose I have a data packet using SPRING to use path A - B - C.  If = B is down, would such packets be discarded or would there be an attempt to = get it to C if one of the other methods for repair is configured?

Anoop
On Tue, May 13, 2014 at 9:35 AM, <int= ernet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF.

        Title           : Use-= cases for Resiliency in SPRING
        Authors         : Pierre Fr= ancois
                     = ;     Clarence Filsfils
                     = ;     Bruno Decraene
                     = ;     Rob Shakir
        Filename        : draft-iet= f-spring-resiliency-use-cases-00.txt
        Pages           : 8         Date            := 2014-05-12

Abstract:
   This document describes the use cases for resiliency in SPRING=
   networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spr= ing-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resili= ency-use-cases-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org
= = https://www.ietf.org/mailman/listinfo/spring

________________________________________= _______
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/sp= ring

___________________= ____________________________
spring mailing list
= spring@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/spring

--047d7b86dd000a918d04fb2e5c17-- From nobody Fri Jun 6 16:51:14 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF241A01E1 for ; Fri, 6 Jun 2014 16:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAMVTH34Ma6k for ; Fri, 6 Jun 2014 16:51:09 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B2C1A0078 for ; Fri, 6 Jun 2014 16:51:09 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-35-53920353abaa Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D1.89.27529.35302935; Fri, 6 Jun 2014 20:07:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 19:51:00 -0400 From: Gregory Mirsky To: Pierre Francois , Anoop Ghanwani Thread-Topic: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt Thread-Index: AQHPgO84+fDgsWqGTE+rC2V1nCt3TJtkRu8AgAAiCgCAAAIgAIAAAfuAgAACYQCAAFHAkA== Date: Fri, 6 Jun 2014 23:51:00 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7C8AE7@eusaamb103.ericsson.se> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> In-Reply-To: <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7C8AE7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonXDeYeVKwwbIZ2hZ7j7tZvHn3h83i +IXfjA7MHltOpnssWfKTyeP72mvMAcxRXDYpqTmZZalF+nYJXBldF44wF7SsYqxYc28OawPj tEmMXYycHBICJhLtT9cyQdhiEhfurWfrYuTiEBI4yihx/8t5NpCEkMAyRonNTUkgNpuAkcSL jT3sILaIQKTE+8lTwGqYBdQllu2/wAJiCwsESjw9NI8FoiZIYtqGzVD1YRLLtu1kBbFZBFQk TrdtBYvzCvhKTOq9zAqxax2zROtGARCbU8BWovdeAzOIzQh03PdTa5ggdolL3HoyH+poAYkl e84zQ9iiEi8f/2OFsBUl9vVPZ4eoz5d4/+E7M8QuQYmTM5+wTGAUnYVk1CwkZbOQlEHEdSQW 7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGBpsYgZF2TIJNdwfjnpeWhxgFOBiV eHgTTk4MFmJNLCuuzD3EKM3BoiTOq32zKlhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY/Ir nRaHQLewJareTXVCFzRapl+V1jz7SnWjhVditO2ahUrbL6/7+OZ+oYeZ3v/p609wvo+89fR6 2kOXCRWpn/+/XOhZ2nlFrGhSH+f0tQq/Nk5jvBvzlHu9vsKL9eHeG/oX/X7zRGFa+tmLcktl hZeUhhmxvX2R4lcgLfUiNPdHk65vehCfuBJLcUaioRZzUXEiAE0tVAyVAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/spring/xVLWRfRqUrKYu6-12iwwPb108es Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 23:51:12 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7C8AE7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pierre, is my understanding correct that authors consider local and e2e protection = in SR to be mutually exclusive for given service path? I think that that ma= y be unnecessary limitation and recommendation of careful consideration and= coordination of defect detection times locally and e2e would suffice. Regards, Greg From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pierre Francois Sent: Friday, June 06, 2014 7:54 AM To: Anoop Ghanwani Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00= .txt Anoop, Well, we have this requirement to be able to have both approaches doable at= the same time on the same network... For example, in SR, you can encode configure your segments as to be protect= ed, or not. If you want local protection, configure segments to be locally protected. If you want path protection, configure segments to not be locally protected= . If you need both for two different services, you'd configure both types and= pick the ones that match the service you need. Cheers, Pierre. On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani > wrote: Pierre, My question is more from a security standpoint. If a node is explicitly identified in the path and that node is down, is it= OK to route around it. I guess what I'm hearing you say is that it depends on what the network ope= rator has configured. They can choose to either discard all such packets, = or route all such packets around the failure, but they cannot choose what i= t to be done on a per-packet basis. Do I have that right? Anoop On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois > wrote: Anoop, You loose the traffic until the moment the ingress node falls back on anoth= er path. If you don't want to have to wait for that failover to happen, then your us= e-case is in another section than the one using path protection ;) Pierre. On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani > wrote: Thanks Pierre. What if the failed component is one of the explicitly identified hops? Anoop On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois > wrote: Hello Anoop, In path protection, section 2, the packets will be dropped until the ingres= s node decides to stop using the failed path and failover. In all other sections, the packets are to be rerouted directly by the nodes= adjacent to the failed component. Cheers, Pierre. On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani > wrote: I have a question about this draft. In section 2, it has the following statement: >>> >From a SPRING viewpoint, we would like to highlight the following requirement: the two configured paths T1 and T2 MUST NOT benefit from local protection. >>> But there is no such statement in subsequent sections. So suppose I have a data packet using SPRING to use path A - B - C. If B i= s down, would such packets be discarded or would there be an attempt to get= it to C if one of the other methods for repair is configured? Anoop On Tue, May 13, 2014 at 9:35 AM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking Worki= ng Group of the IETF. Title : Use-cases for Resiliency in SPRING Authors : Pierre Francois Clarence Filsfils Bruno Decraene Rob Shakir Filename : draft-ietf-spring-resiliency-use-cases-00.txt Pages : 8 Date : 2014-05-12 Abstract: This document describes the use cases for resiliency in SPRING networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_7347100B5761DC41A166AC17F22DF1121B7C8AE7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pierre,

is my understanding corre= ct that authors consider local and e2e protection in SR to be mutually excl= usive for given service path? I think that that may be unnecessary limitation and recommendation of careful consideration and coordination of= defect detection times locally and e2e would suffice.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Pierre Francois
Sent: Friday, June 06, 2014 7:54 AM
To: Anoop Ghanwani
Cc: spring@ietf.org
Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-c= ases-00.txt

 

 

 

Anoop, 

 

Well, we have this requirement to be able to have bo= th approaches doable at the same time on the same network... 

 

For example, in SR, you can encode configure your se= gments as to be protected, or not. 

 

If you want local protection, configure segments to = be locally protected. 

If you want path protection, configure segments to n= ot be locally protected. 

 

If you need both for two different services, you'd c= onfigure both types and pick the ones that match the service you need. = ;

 

Cheers, 

 

Pierre.

 

 

 

On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:



Pierre,

 

My question is more from a security standpoint.=

 

If a node is explicitly identified in the path and t= hat node is down, is it OK to route around it.

 

I guess what I'm hearing you say is that it depends = on what the network operator has configured.  They can choose to eithe= r discard all such packets, or route all such packets around the failure, b= ut they cannot choose what it to be done on a per-packet basis.  Do I have that right?

 

Anoop

 

On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <= pierre.franc= ois@imdea.org> wrote:

 

Anoop, 

 

You loose the traffic until the moment the ingress n= ode falls back on another path. 

 

If you don't want to have to wait for that failover = to happen, then your use-case is in another section than the one using path= protection ;)

 

Pierre.

 

 

 

On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu= > wrote:



Thanks Pierre.

 

What if the failed component is one of the explicitl= y identified hops?

 

Anoop

 

On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <= pierre.franc= ois@imdea.org> wrote:

 

Hello Anoop, 

 

In path protection, section 2, the packets will be d= ropped until the ingress node decides to stop using the failed path and fai= lover. 

 

In all other sections, the packets are to be reroute= d directly by the nodes adjacent to the failed component.

 

Cheers, 

 

Pierre.

 

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu= > wrote:



I have a question about this draft.

 

In section 2, it has the following statement:

>>> 

>From a SPRING viewpoint, we would=
 like to highlight the following
requirement: the two configured paths=
 T1 and T2 MUST NOT benefit from
local protection.

>>> 

 

But there is no such statement in subsequent section= s.

 

So suppose I have a data packet using SPRING to use = path A - B - C.  If B is down, would such packets be discarded or woul= d there be an attempt to get it to C if one of the other methods for repair= is configured?

 

Anoop

On Tue, May 13, 2014 at 9:35 AM, <internet-drafts@ietf.org= > wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF.

        Title           : Use-= cases for Resiliency in SPRING
        Authors         : Pierre Fr= ancois
                     = ;     Clarence Filsfils
                     = ;     Bruno Decraene
                     = ;     Rob Shakir
        Filename        : draft-iet= f-spring-resiliency-use-cases-00.txt
        Pages           : 8         Date            := 2014-05-12

Abstract:
   This document describes the use cases for resiliency in SPRING=
   networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spr= ing-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spring-resili= ency-use-cases-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

 

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

 

 

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

 

 

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring

 

--_000_7347100B5761DC41A166AC17F22DF1121B7C8AE7eusaamb103erics_-- From nobody Sat Jun 7 00:31:10 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602591A02E3 for ; Sat, 7 Jun 2014 00:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV2lOmJonOll for ; Sat, 7 Jun 2014 00:31:02 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28D01A02E7 for ; Sat, 7 Jun 2014 00:30:57 -0700 (PDT) Received: from [86.176.127.74] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WtB5O-0007uk-Hq; Sat, 07 Jun 2014 08:30:42 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_A7D242F5-5BD8-49A0-AF54-DF4DD5479A84" From: Rob Shakir In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7C8AE7@eusaamb103.ericsson.se> Date: Sat, 7 Jun 2014 08:30:39 +0100 Message-Id: <6035CF8F-5D84-435F-976B-A0111FDA9C98@rob.sh> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> <7347100B5761DC41A166AC17F22DF1121B7C8AE7@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/RzYcTDUQjuBuuv4Q8zahTDW_1QI Cc: Pierre Francois , "spring@ietf.org" , Anoop Ghanwani Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 07:31:06 -0000 --Apple-Mail=_A7D242F5-5BD8-49A0-AF54-DF4DD5479A84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Greg, =46rom my perspective, I do not see these as mutually exclusive - could = you point out the wording in the current draft(s) that implies such = please? There is no restriction such that a head-end must select segments that = are not locally protected when implementing e2e protection - we see = applications whereby there will be a requirement for strict performance = guarantees, such that tolerating the variance introduced by local = protection is unacceptable (and hence the head-end selects non-revertive = segments) - along with those where such variance is tolerable (and hence = protected segments are chosen). It is simply up to the configuration of = the head-end node for a particular LSP as to how it chooses to provide = protection. As you say, in the case where only e2e protection is implemented - then = it=92s critical to consider how defects are detected, and what the delay = in such defects being detected is, such that the path-protection = implemented is suitable for the transported application. Kind regards, r. On 7 Jun 2014, at 00:51, Gregory Mirsky = wrote: > Hi Pierre, > is my understanding correct that authors consider local and e2e = protection in SR to be mutually exclusive for given service path? I = think that that may be unnecessary limitation and recommendation of = careful consideration and coordination of defect detection times locally = and e2e would suffice. > =20 > Regards, > Greg > =20 > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pierre = Francois > Sent: Friday, June 06, 2014 7:54 AM > To: Anoop Ghanwani > Cc: spring@ietf.org > Subject: Re: [spring] I-D Action: = draft-ietf-spring-resiliency-use-cases-00.txt > =20 > =20 > =20 > Anoop,=20 > =20 > Well, we have this requirement to be able to have both approaches = doable at the same time on the same network...=20 > =20 > For example, in SR, you can encode configure your segments as to be = protected, or not.=20 > =20 > If you want local protection, configure segments to be locally = protected.=20 > If you want path protection, configure segments to not be locally = protected.=20 > =20 > If you need both for two different services, you'd configure both = types and pick the ones that match the service you need.=20 > =20 > Cheers,=20 > =20 > Pierre. > =20 > =20 > =20 > On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani = wrote: >=20 >=20 > Pierre, > =20 > My question is more from a security standpoint. > =20 > If a node is explicitly identified in the path and that node is down, = is it OK to route around it. > =20 > I guess what I'm hearing you say is that it depends on what the = network operator has configured. They can choose to either discard all = such packets, or route all such packets around the failure, but they = cannot choose what it to be done on a per-packet basis. Do I have that = right? > =20 > Anoop > =20 >=20 > On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois = wrote: > =20 > Anoop,=20 > =20 > You loose the traffic until the moment the ingress node falls back on = another path.=20 > =20 > If you don't want to have to wait for that failover to happen, then = your use-case is in another section than the one using path protection = ;) > =20 > Pierre. > =20 > =20 > =20 > On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani = wrote: >=20 >=20 > Thanks Pierre. > =20 > What if the failed component is one of the explicitly identified hops? > =20 > Anoop > =20 >=20 > On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = wrote: > =20 > Hello Anoop,=20 > =20 > In path protection, section 2, the packets will be dropped until the = ingress node decides to stop using the failed path and failover.=20 > =20 > In all other sections, the packets are to be rerouted directly by the = nodes adjacent to the failed component. > =20 > Cheers,=20 > =20 > Pierre. > =20 > On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani = wrote: >=20 >=20 > I have a question about this draft. > =20 > In section 2, it has the following statement: > >>>=20 > >=46rom a SPRING viewpoint, we would like to highlight the following > requirement: the two configured paths T1 and T2 MUST NOT benefit from > local protection. > >>>=20 > =20 > But there is no such statement in subsequent sections. > =20 > So suppose I have a data packet using SPRING to use path A - B - C. = If B is down, would such packets be discarded or would there be an = attempt to get it to C if one of the other methods for repair is = configured? > =20 > Anoop >=20 > On Tue, May 13, 2014 at 9:35 AM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF. >=20 > Title : Use-cases for Resiliency in SPRING > Authors : Pierre Francois > Clarence Filsfils > Bruno Decraene > Rob Shakir > Filename : = draft-ietf-spring-resiliency-use-cases-00.txt > Pages : 8 > Date : 2014-05-12 >=20 > Abstract: > This document describes the use cases for resiliency in SPRING > networks. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_A7D242F5-5BD8-49A0-AF54-DF4DD5479A84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Greg,

=46rom my perspective, I do not see these as mutually = exclusive - could you point out the wording in the current draft(s) that = implies such please?

There is no restriction such that a head-end must select = segments that are not locally protected when implementing e2e protection = - we see applications whereby there will be a requirement for strict = performance guarantees, such that tolerating the variance introduced by = local protection is unacceptable (and hence the head-end selects = non-revertive segments) - along with those where such variance is = tolerable (and hence protected segments are chosen). It is simply up to = the configuration of the head-end node for a particular LSP as to how it = chooses to provide protection.

As you say, in the case where only e2e protection is = implemented - then it=92s critical to consider how defects are detected, = and what the delay in such defects being detected is, such that the = path-protection implemented is suitable for the transported = application.

Kind = regards,
r.

On 7 Jun 2014, at 00:51, Gregory Mirsky = <gregory.mirsky@ericsson.com> wrote:

Hi Pierre,
is my understanding correct that authors = consider local and e2e protection in SR to be mutually exclusive for = given service path? I think that that may be unnecessary limitation and = recommendation of careful consideration and coordination of defect = detection times locally and e2e would suffice.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         Greg
 
From: spring [mailto:spring-bounces@ietf.org= ] On = Behalf Of Pierre = Francois
Sent: Friday, June 06, 2014 7:54 = AM
To: Anoop Ghanwani
Cc: spring@ietf.org
Subject: Re: [spring] I-D Action: = draft-ietf-spring-resiliency-use-cases-00.txt
 
 
 
Anoop, 
 
Well, we have this requirement to be able = to have both approaches doable at the same time on the same = network... 
 
For example, in SR, you can encode configure your = segments as to be protected, or not. 
 
If you want local protection, configure = segments to be locally protected. 
If you want path protection, configure segments to not be = locally protected. 
 
If you need both for two different services, you'd = configure both types and pick the ones that match the service you = need. 
 
Cheers, 
 
Pierre.
 
 
 
On Jun 6, 2014, at 4:45 PM, Anoop = Ghanwani <anoop@alumni.duke.edu> wrote:


Pierre,
 
My question is more from a security standpoint.
 
If a node is explicitly identified in the = path and that node is down, is it OK to route around it.
 
I guess what I'm hearing you say is that = it depends on what the network operator has configured.  They can = choose to either discard all such packets, or route all such packets = around the failure, but they cannot choose what it to be done on a = per-packet basis.  Do I have that right?
 
Anoop

 

On Fri, Jun 6, 2014 at 7:38 AM, Pierre = Francois <pierre.francois@imdea.org> wrote:
 
Anoop, 
 
You loose the traffic until the moment the ingress node falls = back on another path. 
 
If you don't want to have to wait for that failover = to happen, then your use-case is in another section than the one using = path protection ;)
 
Pierre.
 
 
 
On Jun 6, 2014, at = 4:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:


Thanks Pierre.
 
What if the failed component is one of = the explicitly identified hops?
 
Anoop

 

On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <pierre.francois@imdea.org> wrote:
 
Hello Anoop, 
 
In path protection, section 2, the packets will be = dropped until the ingress node decides to stop using the failed path and = failover. 
 
In all other sections, the packets are to be rerouted = directly by the nodes adjacent to the failed component.
 
Cheers, 
 
Pierre.
 
On Jun 5, 2014, at = 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:


I have a question about this draft.
 
In section 2, it has the following = statement:
>>> 
>=46rom a =
SPRING viewpoint, we would like to highlight the following
requirement: the two configured =
paths T1 and T2 MUST NOT benefit from
local protection.
>>> 
 
But = there is no such statement in subsequent sections.
 
So suppose I have a data packet using = SPRING to use path A - B - C.  If B is down, would such packets be = discarded or would there be an attempt to get it to C if one of the = other methods for repair is configured?
 

Anoop

On Tue, May 13, 2014 = at 9:35 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
 This draft is a work = item of the Source Packet Routing in Networking Working Group of the = IETF.

        Title =           : Use-cases for Resiliency in = SPRING
        Authors     =     : Pierre Francois
      =                     = Clarence Filsfils
          =                 Bruno = Decraene
              =             Rob Shakir
  =       Filename        : = draft-ietf-spring-resiliency-use-cases-00.txt
  =       Pages           : 8
        Date         =    : 2014-05-12

Abstract:
   This document describes the use cases for = resiliency in SPRING
   networks.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-u= se-cases/

There's also a htmlized = version available at:
http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cas= es-00


Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
 
_________________________________= ______________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring=
= --Apple-Mail=_A7D242F5-5BD8-49A0-AF54-DF4DD5479A84-- From nobody Mon Jun 9 01:08:33 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487F71A001B for ; Mon, 9 Jun 2014 01:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDM8_frCOfag for ; Mon, 9 Jun 2014 01:07:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C061A0019 for ; Mon, 9 Jun 2014 01:07:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFF38302; Mon, 09 Jun 2014 08:07:54 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 09:07:53 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 16:07:48 +0800 From: Xuxiaohu To: "Eric Vyncke (evyncke)" , Hannes Gredler , "Stefano Previdi (sprevidi)" Thread-Topic: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPSRpHfoJZL7ndH0WDfBS+IHX9iprz+/GAgALKkNeAAFd2AIAAO5eAgF4+uYCAA9FWAIAEsg2AgAWcagCAAAh3AIAFDiWw Date: Mon, 9 Jun 2014 08:07:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827F3D1@NKGEML512-MBS.china.huawei.com> References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201403281736.s2SHawV72952@magenta.juniper.net> <20140328212333.GE30644@juniper.net> <20140606091754.GB12354@juniper.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Qa9w6Tlp9xUlDy72vwwR4Vw0FV8 Cc: Yakov Rekhter , "" , "Alvaro Retana \(aretana\)" , "John G. Scudder" Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 08:08:07 -0000 > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Eric Vyncke > (evyncke) > Sent: Friday, June 06, 2014 5:48 PM > To: Hannes Gredler; Stefano Previdi (sprevidi) > Cc: Yakov Rekhter; ; John G. Scudder; Alvaro Retana (are= tana) > Subject: Re: [spring] WG Adoption Call for > draft-martin-spring-segment-routing-ipv6-use-cases >=20 > Hannes, >=20 > I am following this thread from far away but I wonder about: >=20 > On 6/06/14 11:17, "Hannes Gredler" wrote: > > > > 1. There is little to no SP traction on IPv6-SR. > > those SPs who have voiced support in all reality > > can be served well with nested IP tunnels based on > > exisiting protocols (GRE, IPIP, L2TPv3 ) >=20 > Tunnels are also expensive (cfr point below) but if you want to enforce a= specific > route for TE, then, I am afraid that this will be a lot of specific confi= guration (or > states if dynamic) in a lot of nodes... As well as a lot of specific rout= es towards > those tunnels. So, kind of heavy. Agree that nested IP tunnels are expensive. However, the SRH which contains= an ordered list of IPv6 addresses seems a bit heavy as well (e.g., the MTU= issue), especially when the number of specified hops along the explicit pa= th is very large. Why not use an ordered list of short ids, instead of an o= rdered list of IPv6 addresses to represent an explicit path while still all= owing the underlay is IPv6 network? IMHO, the MPLS label stack seems like a= n ideal candidate for that ordered list of short ids. To some extent, the M= PLS layer is now an overlay as opposed to the IPv6 underlay (see http://too= ls.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00). Or do you = believe the MTU issue is not a problem anymore in practice? > Not to mention that with SRH you could have different paths among two > end-points based on the application (web vs video) identified by some mea= ns > (such as layer-4 information), way more complex to do it with tunnels and= 'plain' > routing. >=20 > > 4. the cost of adding explicit routing forwarding capabilities > > to IPv6 forwarding hardware is now visible (and guess what - its > >expensive > > to implement on high speed (100GBIT/s lookup engines - > > (parsing IPv6-extensions headers does require a lot of memory > >references) >=20 > I am sure that you know how source routing works, only the router in the > destination address main IPv6 header field needs to inspect the SR header= , all > others routers can safely act only on the DA and ignoring the extension h= eader > chain (of course, if ACL are applied on layer-4 you need to parse the ext= ension > header chain but this is the same with or without SR). In the approach as I mentioned above, it only requires those specified hops= along the explicit path to be upgraded as well (i.e., interpret the top la= bel of the MPLS packet into the IPv6 address of the next specified hop and = then forward the packet to that hop via an IPv6 tunnel instead of an MPLS L= SP tunnel). In other words, its deployment cost is much similar with that o= f the SRH-based approach. Best regards, Xiaohu > Hope that my comment helps clarifying the context >=20 > -=E9ric >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jun 9 09:15:32 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23071A025F for ; Mon, 9 Jun 2014 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSHsxmhLb-lu for ; Mon, 9 Jun 2014 09:15:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A191A0253 for ; Mon, 9 Jun 2014 09:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2579; q=dns/txt; s=iport; t=1402330529; x=1403540129; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=EBwch3wGdUx8WsjWlQtpFJtLdPwbiAfwyP+N3p8cW2w=; b=Od2byqPFZSVEyPwWyrnhJJapRLTGueLDg0gDZ3sr+E9cQg+S4OTJg2Fh A/Gf2EHvtYx0tR57doVlSBxbPKIo21hOO7p4mHrr9quZtK/B+5aovbRVp oCiUs76FZPtcBIDxx/c7ZgpP5ASnp0hrUaSkZ0uNYwBhlla/NNbjx4DcZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQTABjdlVOtJA2N/2dsb2JhbABZgw1SUgQDqlMRBQECmQ6BExZ1hAMBAQEDATo9BwsCARkDAQIfEDIbAggCBBMJiDEICAXLOxeFXYkcgyWBFgSaIYFCkgOBfIFAbIFD X-IronPort-AV: E=Sophos;i="4.98,1003,1392163200"; d="scan'208";a="331798665" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 09 Jun 2014 16:15:28 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s59GFSrJ017940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2014 16:15:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.223]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 9 Jun 2014 11:15:27 -0500 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-previdi-6man-segment-routing-header-01.txt Thread-Index: AQHPg/1zk6f/z8C8Ck+H89CY5k/8sQ== Date: Mon, 9 Jun 2014 16:15:27 +0000 Message-ID: References: <20140609161116.29888.49981.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.217.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <863921A5DEAD0B45BDA85ECC7F5C616D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/BdbYp6a4uXmgNeK55X4I3WZN0cQ Subject: [spring] Fwd: New Version Notification for draft-previdi-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:15:31 -0000 All, this is an update of the the Segment Routing over IPv6 dataplane draft (ver= sion -02). The changes are: . added "Abstract Model" section. This section was, initially, in=20 draft-filsfils-spring-segment-routing and it's now moved in the=20 SR-IPv6 draft (the section content is unchanged). . Added Adj-SID definition. Thanks. s. Begin forwarded message: > From: > Subject: New Version Notification for draft-previdi-6man-segment-routing-= header-01.txt > Date: June 9, 2014 6:11:16 PM GMT+02:00 > To: Stefano Previdi , Ida Leung , Brian Field , Clarence Filsfils , Stefano Previdi , Ida Leung , Brian Field , Clarence Fil= sfils >=20 >=20 > A new version of I-D, draft-previdi-6man-segment-routing-header-01.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-previdi-6man-segment-routing-header > Revision: 01 > Title: IPv6 Segment Routing Header (SRH) > Document date: 2014-06-09 > Group: Individual Submission > Pages: 28 > URL: http://www.ietf.org/internet-drafts/draft-previdi-6man-se= gment-routing-header-01.txt > Status: https://datatracker.ietf.org/doc/draft-previdi-6man-segme= nt-routing-header/ > Htmlized: http://tools.ietf.org/html/draft-previdi-6man-segment-rou= ting-header-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-6man-seg= ment-routing-header-01 >=20 > Abstract: > Segment Routing (SR) allows a node to steer a packet through a > controlled set of instructions, called segments, by prepending a SR > header to the packet. A segment can represent any instruction, > topological or service-based. SR allows to enforce a flow through > any path (topological, or application/service based) while > maintaining per-flow state only at the ingress node to the SR domain. >=20 > Segment Routing can be applied to the IPv6 data plane with the > addition of a new type of Routing Extension Header. This draft > describes the Segment Routing Extension Header Type and how it is > used by SR capable nodes. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon Jun 9 19:15:06 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40441A032E for ; Mon, 9 Jun 2014 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx3l9ZGqBqwk for ; Mon, 9 Jun 2014 19:14:59 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7431A0336 for ; Mon, 9 Jun 2014 19:14:58 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-66-5396196553aa Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 2A.98.27529.56916935; Mon, 9 Jun 2014 22:30:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 22:14:55 -0400 From: Gregory Mirsky To: Rob Shakir Thread-Topic: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt Thread-Index: AQHPgiJoZXJQ+rUh1kyPeBYZozEbeZtpnP2w Date: Tue, 10 Jun 2014 02:14:55 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7CC1CD@eusaamb103.ericsson.se> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> <7347100B5761DC41A166AC17F22DF1121B7C8AE7@eusaamb103.ericsson.se> <6035CF8F-5D84-435F-976B-A0111FDA9C98@rob.sh> In-Reply-To: <6035CF8F-5D84-435F-976B-A0111FDA9C98@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7CC1CDeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonXDdVclqwQddRU4u9x90s3rz7w2bR dnwvm8XxC78ZHVg8tpxM91iy5CeTx/e115g9lmzdxRbAEsVlk5Kak1mWWqRvl8CVcf5DSkHL T8aKaa+Psjcwbr7G2MXIySEhYCLx/cFhNghbTOLCvfVANheHkMBRRolD52czQTjLGCU239sB VsUmYCTxYmMPO4gtIiAt0d/TABZnFqiTWHrrAUsXIweHsECgxMZ12hAlQRL9vxuhyo0kvvfO YwGxWQRUJZZdmwzWyivgK3Fg+SOoXYtYJO69PMEKkuAUsJL4PrWLGcRmBLru+6k1TBC7xCVu PZnPBHG1gMSSPeeZIWxRiZeP/7FC2IoS+/qns4PcwyyQL3FpbyLELkGJkzOfsExgFJ2FZNIs hKpZSKogSnQkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwcpcWpZbnpRgabGIGRd0yCTXcH 456XlocYBTgYlXh4F7RODRZiTSwrrsw9xCjNwaIkzqt9sypYSCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2Pc0xB2K65fHEGf/graS3V/spr05Ke40MbnXq7T/b8/knx3LtX58yY76Yvtpha/ P+zcWNdSw9cjXCnH/CBGaPa+9g2NZ7fW3Q08eaSjnS/s8QOt45VNiu8tysyPRkZG3VN38E9Z L6zAoxCkeuiN2hbn57Hz9F+qb3Betz+zyLvL9HfeBu8fmUosxRmJhlrMRcWJAKwuhGmdAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/spring/1uclx76AbwE7IqXRSOnYwgwToEM Cc: Pierre Francois , "spring@ietf.org" , Anoop Ghanwani Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 02:15:03 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7CC1CDeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob, I think that it is about the same note in the Section 2 Path protection: From a SPRING viewpoint, we would like to highlight the following requirement: the two configured paths T1 and T2 MUST NOT benefit from local protection. If authors are planning to change the wording then I'll wait for the update= . Regards, Greg From: Rob Shakir [mailto:rjs@rob.sh] Sent: Saturday, June 07, 2014 12:31 AM To: Gregory Mirsky Cc: Pierre Francois; Anoop Ghanwani; spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00= .txt Hi Greg, >From my perspective, I do not see these as mutually exclusive - could you p= oint out the wording in the current draft(s) that implies such please? There is no restriction such that a head-end must select segments that are = not locally protected when implementing e2e protection - we see application= s whereby there will be a requirement for strict performance guarantees, su= ch that tolerating the variance introduced by local protection is unaccepta= ble (and hence the head-end selects non-revertive segments) - along with th= ose where such variance is tolerable (and hence protected segments are chos= en). It is simply up to the configuration of the head-end node for a partic= ular LSP as to how it chooses to provide protection. As you say, in the case where only e2e protection is implemented - then it'= s critical to consider how defects are detected, and what the delay in such= defects being detected is, such that the path-protection implemented is su= itable for the transported application. Kind regards, r. On 7 Jun 2014, at 00:51, Gregory Mirsky > wrote: Hi Pierre, is my understanding correct that authors consider local and e2e protection = in SR to be mutually exclusive for given service path? I think that that ma= y be unnecessary limitation and recommendation of careful consideration and= coordination of defect detection times locally and e2e would suffice. Regards, Greg From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pierre Francois Sent: Friday, June 06, 2014 7:54 AM To: Anoop Ghanwani Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00= .txt Anoop, Well, we have this requirement to be able to have both approaches doable at= the same time on the same network... For example, in SR, you can encode configure your segments as to be protect= ed, or not. If you want local protection, configure segments to be locally protected. If you want path protection, configure segments to not be locally protected= . If you need both for two different services, you'd configure both types and= pick the ones that match the service you need. Cheers, Pierre. On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani > wrote: Pierre, My question is more from a security standpoint. If a node is explicitly identified in the path and that node is down, is it= OK to route around it. I guess what I'm hearing you say is that it depends on what the network ope= rator has configured. They can choose to either discard all such packets, = or route all such packets around the failure, but they cannot choose what i= t to be done on a per-packet basis. Do I have that right? Anoop On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois > wrote: Anoop, You loose the traffic until the moment the ingress node falls back on anoth= er path. If you don't want to have to wait for that failover to happen, then your us= e-case is in another section than the one using path protection ;) Pierre. On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani > wrote: Thanks Pierre. What if the failed component is one of the explicitly identified hops? Anoop On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois > wrote: Hello Anoop, In path protection, section 2, the packets will be dropped until the ingres= s node decides to stop using the failed path and failover. In all other sections, the packets are to be rerouted directly by the nodes= adjacent to the failed component. Cheers, Pierre. On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani > wrote: I have a question about this draft. In section 2, it has the following statement: >>> >From a SPRING viewpoint, we would like to highlight the following requirement: the two configured paths T1 and T2 MUST NOT benefit from local protection. >>> But there is no such statement in subsequent sections. So suppose I have a data packet using SPRING to use path A - B - C. If B i= s down, would such packets be discarded or would there be an attempt to get= it to C if one of the other methods for repair is configured? Anoop On Tue, May 13, 2014 at 9:35 AM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking Worki= ng Group of the IETF. Title : Use-cases for Resiliency in SPRING Authors : Pierre Francois Clarence Filsfils Bruno Decraene Rob Shakir Filename : draft-ietf-spring-resiliency-use-cases-00.txt Pages : 8 Date : 2014-05-12 Abstract: This document describes the use cases for resiliency in SPRING networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_7347100B5761DC41A166AC17F22DF1121B7CC1CDeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob,=

I think that it is about = the same note in the Section 2 Path protection:

   From a SPRIN= G viewpoint, we would like to highlight the following

   requirement:= the two configured paths T1 and T2 MUST NOT benefit from=

   local protec= tion.

If authors are planning t= o change the wording then I’ll wait for the update.=

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

From: Rob Shak= ir [mailto:rjs@rob.sh]
Sent: Saturday, June 07, 2014 12:31 AM
To: Gregory Mirsky
Cc: Pierre Francois; Anoop Ghanwani; spring@ietf.org
Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-c= ases-00.txt

 

Hi Greg,

 

From my perspective, I do not see these as mutually = exclusive - could you point out the wording in the current draft(s) that im= plies such please?

 

There is no restriction such that a head-end must se= lect segments that are not locally protected when implementing e2e protecti= on - we see applications whereby there will be a requirement for strict per= formance guarantees, such that tolerating the variance introduced by local protection is unacceptable (and hence the= head-end selects non-revertive segments) - along with those where such var= iance is tolerable (and hence protected segments are chosen). It is simply = up to the configuration of the head-end node for a particular LSP as to how it chooses to provide protection.=

 

As you say, in the case where only e2e protection is= implemented - then it’s critical to consider how defects are detecte= d, and what the delay in such defects being detected is, such that the path= -protection implemented is suitable for the transported application.

 

Kind regards,

r.

 

On 7 Jun 2014, at 00:51, Gregory Mirsky <gregory.mirsky@ericsson.com>= wrote:



Hi Pierre,

is my understanding corre= ct that authors consider local and e2e protection in SR to be mutually excl= usive for given service path? I think that that may be unnecessary limitation and recommendation of careful consideration and coordination of= defect detection times locally and e2e would suffice.

 <= /p>

    &= nbsp;           Regards,<= /span>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: spring [mailto:spring-bounces@ietf.org= ] On Behalf Of Pierre Francois
Sent: Friday, June= 06, 2014 7:54 AM
To: Anoop Ghanwani=
Cc: spring@ietf.org
Subject: Re: [spri= ng] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt

 

 

 

Anoop, 

 

Well, we have this requirement to be able to have bo= th approaches doable at the same time on the same network... 

 

For example, in SR, you can encode configure your se= gments as to be protected, or not. 

 

If you want local protection, configure segments to = be locally protected. 

If you want path protection, configure segments to n= ot be locally protected. 

 

If you need both for two different services, you'd c= onfigure both types and pick the ones that match the service you need. = ;

 

Cheers, 

 

Pierre.

 

 

 

On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani <anoop@alum= ni.duke.edu> wrote:




Pierre,

 

My question is more from a security standpoint.=

 

If a node is explicitly identified in the path and t= hat node is down, is it OK to route around it.

 

I guess what I'm hearing you say is that it depends = on what the network operator has configured.  They can choose to eithe= r discard all such packets, or route all such packets around the failure, b= ut they cannot choose what it to be done on a per-packet basis.  Do I have that right?

 

Anoop

 

On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <= pierre.francois@imdea.org> wrote:

 

Anoop, 

 

You loose the traffic until the moment the ingress n= ode falls back on another path. 

 

If you don't want to have to wait for that failover = to happen, then your use-case is in another section than the one using path= protection ;)

 

Pierre.

 

 

 

On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:




Thanks Pierre.

 

What if the failed component is one of the explicitl= y identified hops?

 

Anoop

 

On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <= pierre.francois@imdea.org> wrote:

 

Hello Anoop, 

 

In path protection, section 2, the packets will be d= ropped until the ingress node decides to stop using the failed path and fai= lover. 

 

In all other sections, the packets are to be reroute= d directly by the nodes adjacent to the failed component.

 

Cheers, 

 

Pierre.

 

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:




I have a question about this draft.

 

In section 2, it has the following statement:

>>> 

>From a SPRING viewpoint, we would=
 like to highlight the following
requirement: the two configured paths=
 T1 and T2 MUST NOT benefit from
local protection.

>>> 

 

But there is no such statement in subsequent section= s.

 

So suppose I have a data packet using SPRING to use = path A - B - C.  If B is down, would such packets be discarded or woul= d there be an attempt to get it to C if one of the other methods for repair= is configured?

 

Anoop

On Tue, May 13, 2014 at 9:35 AM, <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF.

        Title           : Use-= cases for Resiliency in SPRING
        Authors         : Pierre Fr= ancois
                     = ;     Clarence Filsfils
                     = ;     Bruno Decraene
                     = ;     Rob Shakir
        Filename        : draft-iet= f-spring-resiliency-use-cases-00.txt
        Pages           : 8         Date            := 2014-05-12

Abstract:
   This document describes the use cases for resiliency in SPRING=
   networks.


The IETF datatracker status page for this draft is:
https://datatracke= r.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/= html/draft-ietf-spring-resiliency-use-cases-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring

 

_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring

 

 

_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring

 

 

_______________________________________________
spring mailing list
spring@ietf= .org
https://www.ietf.org/mailman/listinfo/spring

 

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring

 

--_000_7347100B5761DC41A166AC17F22DF1121B7CC1CDeusaamb103erics_-- From nobody Tue Jun 10 03:34:54 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4911A0040 for ; Tue, 10 Jun 2014 03:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amkNjkU6TOTU for ; Tue, 10 Jun 2014 03:34:49 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EF41A002A for ; Tue, 10 Jun 2014 03:34:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 86C5B1BA8A1; Tue, 10 Jun 2014 12:34:20 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi4Y6PqyKo4W; Tue, 10 Jun 2014 12:34:20 +0200 (CEST) Received: from dhcp-10-61-97-56.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 28B1E1BA89F; Tue, 10 Jun 2014 12:34:15 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D7CEB63-5032-4067-A64C-4B3B9741FB1F" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pierre Francois In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7CC1CD@eusaamb103.ericsson.se> Date: Tue, 10 Jun 2014 12:34:39 +0200 Message-Id: <29AD70F9-5487-4531-8CB8-9F71506281FE@imdea.org> References: <20140513163528.15975.8536.idtracker@ietfa.amsl.com> <0935BC0D-5BAB-485F-AA60-B399558C937A@imdea.org> <15E781BC-1EC8-409C-8F59-8CE5D2704904@imdea.org> <6F772E4D-9358-4724-A48C-680E103207A6@imdea.org> <7347100B5761DC41A166AC17F22DF1121B7C8AE7@eusaamb103.ericsson.se> <6035CF8F-5D84-435F-976B-A0111FDA9C98@rob.sh> <7347100B5761DC41A166AC17F22DF1121B7CC1CD@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/fn_iOmvrQ1l29Utbb8cxX8A5KjE Cc: Anoop Ghanwani , "spring@ietf.org" , Rob Shakir Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 10:34:52 -0000 --Apple-Mail=_9D7CEB63-5032-4067-A64C-4B3B9741FB1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Greg,=20 Maybe a confusion comes from the fact that this sentence only applies to = the case of that section. Section 5 mentions that the various approaches described in the doc = should be applicable at the same time in a given network.=20 I'll try to clarify this.=20 Pierre. On Jun 10, 2014, at 4:14 AM, Gregory Mirsky = wrote: > Hi Rob, > I think that it is about the same note in the Section 2 Path = protection: > =46rom a SPRING viewpoint, we would like to highlight the following > requirement: the two configured paths T1 and T2 MUST NOT benefit = from > local protection. > If authors are planning to change the wording then I=92ll wait for the = update. > =20 > Regards, > Greg > From: Rob Shakir [mailto:rjs@rob.sh]=20 > Sent: Saturday, June 07, 2014 12:31 AM > To: Gregory Mirsky > Cc: Pierre Francois; Anoop Ghanwani; spring@ietf.org > Subject: Re: [spring] I-D Action: = draft-ietf-spring-resiliency-use-cases-00.txt > =20 > Hi Greg, > =20 > =46rom my perspective, I do not see these as mutually exclusive - = could you point out the wording in the current draft(s) that implies = such please? > =20 > There is no restriction such that a head-end must select segments that = are not locally protected when implementing e2e protection - we see = applications whereby there will be a requirement for strict performance = guarantees, such that tolerating the variance introduced by local = protection is unacceptable (and hence the head-end selects non-revertive = segments) - along with those where such variance is tolerable (and hence = protected segments are chosen). It is simply up to the configuration of = the head-end node for a particular LSP as to how it chooses to provide = protection. > =20 > As you say, in the case where only e2e protection is implemented - = then it=92s critical to consider how defects are detected, and what the = delay in such defects being detected is, such that the path-protection = implemented is suitable for the transported application. > =20 > Kind regards, > r. > =20 > On 7 Jun 2014, at 00:51, Gregory Mirsky = wrote: >=20 >=20 > Hi Pierre, > is my understanding correct that authors consider local and e2e = protection in SR to be mutually exclusive for given service path? I = think that that may be unnecessary limitation and recommendation of = careful consideration and coordination of defect detection times locally = and e2e would suffice. > =20 > Regards, > Greg > =20 > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pierre = Francois > Sent: Friday, June 06, 2014 7:54 AM > To: Anoop Ghanwani > Cc: spring@ietf.org > Subject: Re: [spring] I-D Action: = draft-ietf-spring-resiliency-use-cases-00.txt > =20 > =20 > =20 > Anoop,=20 > =20 > Well, we have this requirement to be able to have both approaches = doable at the same time on the same network...=20 > =20 > For example, in SR, you can encode configure your segments as to be = protected, or not.=20 > =20 > If you want local protection, configure segments to be locally = protected.=20 > If you want path protection, configure segments to not be locally = protected.=20 > =20 > If you need both for two different services, you'd configure both = types and pick the ones that match the service you need.=20 > =20 > Cheers,=20 > =20 > Pierre. > =20 > =20 > =20 > On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani = wrote: >=20 >=20 >=20 > Pierre, > =20 > My question is more from a security standpoint. > =20 > If a node is explicitly identified in the path and that node is down, = is it OK to route around it. > =20 > I guess what I'm hearing you say is that it depends on what the = network operator has configured. They can choose to either discard all = such packets, or route all such packets around the failure, but they = cannot choose what it to be done on a per-packet basis. Do I have that = right? > =20 > Anoop > =20 >=20 > On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois = wrote: > =20 > Anoop,=20 > =20 > You loose the traffic until the moment the ingress node falls back on = another path.=20 > =20 > If you don't want to have to wait for that failover to happen, then = your use-case is in another section than the one using path protection = ;) > =20 > Pierre. > =20 > =20 > =20 > On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani = wrote: >=20 >=20 >=20 > Thanks Pierre. > =20 > What if the failed component is one of the explicitly identified hops? > =20 > Anoop > =20 >=20 > On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois = wrote: > =20 > Hello Anoop,=20 > =20 > In path protection, section 2, the packets will be dropped until the = ingress node decides to stop using the failed path and failover.=20 > =20 > In all other sections, the packets are to be rerouted directly by the = nodes adjacent to the failed component. > =20 > Cheers,=20 > =20 > Pierre. > =20 > On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani = wrote: >=20 >=20 >=20 > I have a question about this draft. > =20 > In section 2, it has the following statement: > >>>=20 > >=46rom a SPRING viewpoint, we would like to highlight the following > requirement: the two configured paths T1 and T2 MUST NOT benefit from > local protection. > >>>=20 > =20 > But there is no such statement in subsequent sections. > =20 > So suppose I have a data packet using SPRING to use path A - B - C. = If B is down, would such packets be discarded or would there be an = attempt to get it to C if one of the other methods for repair is = configured? > =20 > Anoop >=20 > On Tue, May 13, 2014 at 9:35 AM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Source Packet Routing in Networking = Working Group of the IETF. >=20 > Title : Use-cases for Resiliency in SPRING > Authors : Pierre Francois > Clarence Filsfils > Bruno Decraene > Rob Shakir > Filename : = draft-ietf-spring-resiliency-use-cases-00.txt > Pages : 8 > Date : 2014-05-12 >=20 > Abstract: > This document describes the use cases for resiliency in SPRING > networks. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_9D7CEB63-5032-4067-A64C-4B3B9741FB1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Greg, 

Maybe a confusion comes from the fact = that this sentence only applies to the case of that = section.
Section 5 mentions that the various approaches = described in the doc should be applicable at the same time in a given = network. 

I'll try to clarify = this. 

Pierre.


=
On Jun 10, 2014, at 4:14 AM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi = Rob,
I think that it is about the same note in the = Section 2 Path protection:
   =46rom a SPRING = viewpoint, we would like to highlight the = following
   requirement: the two configured paths = T1 and T2 MUST NOT benefit from
   local = protection.
If authors are planning to change the wording = then I=92ll wait for the update.
 
 
Hi Greg,
 
=46rom= my perspective, I do not see these as mutually exclusive - could you = point out the wording in the current draft(s) that implies such = please?
As = you say, in the case where only e2e protection is implemented - then = it=92s critical to consider how defects are detected, and what the delay = in such defects being detected is, such that the path-protection = implemented is suitable for the transported = application.
Kind = regards,
On 7 = Jun 2014, at 00:51, Gregory Mirsky <gregory.mirsky@ericsson.com> = wrote:
Hi = Pierre,
is my understanding correct that authors = consider local and e2e protection in SR to be mutually exclusive for = given service path? I think that that may be unnecessary limitation and = recommendation of careful consideration and coordination of defect = detection times locally and e2e would = suffice.
 
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pierre = Francois
Sent: Friday, June 06, 2014 7:54 = AM
To: Anoop = Ghanwani
Cc: spring@ietf.org
Subject: Re: [spring] I-D Action: = draft-ietf-spring-resiliency-use-cases-00.txt
For = example, in SR, you can encode configure your segments as to be = protected, or not. 
 
If = you want local protection, configure segments to be locally = protected. 
If = you need both for two different services, you'd configure both types and = pick the ones that match the service you = need. 
On = Jun 6, 2014, at 4:45 PM, Anoop Ghanwani <My = question is more from a security = standpoint.
 

You = loose the traffic until the moment the ingress node falls back on = another path. 
If = you don't want to have to wait for that failover to happen, then your = use-case is in another section than the one using path protection = ;)
 
 
 
 

 
In = path protection, section 2, the packets will be dropped until the = ingress node decides to stop using the failed path and = failover. 
In = all other sections, the packets are to be rerouted directly by the nodes = adjacent to the failed component.
 
Cheers, 
 
Pierre.

<= /html>= --Apple-Mail=_9D7CEB63-5032-4067-A64C-4B3B9741FB1F-- From nobody Tue Jun 17 19:28:29 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D951A01F1 for ; Tue, 17 Jun 2014 19:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSeNwEFOsOex for ; Tue, 17 Jun 2014 19:28:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D94B1A01C5 for ; Tue, 17 Jun 2014 19:28:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFN74986; Wed, 18 Jun 2014 02:28:23 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 03:28:22 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 10:28:14 +0800 From: Xuxiaohu To: "" Thread-Topic: New Version Notification for draft-xu-spring-sfc-use-case-01.txt Thread-Index: AQHPipxuOL+tsueljkWKFZ07diYiIJt2I8FA Date: Wed, 18 Jun 2014 02:28:14 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/0BDjwExUGAIGX8r5MYUihgA4iSw Subject: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 02:28:27 -0000 SGkgYWxsLA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW5pbmcgdXNlIGNhc2UgZm9yIFNQUklORy4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUvUm9iaW4vSGltYW5zaHUNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxOCwgMjAxNCAx MDoyNCBBTQ0KPiBUbzogTGl6aGVuYmluOyBYdXhpYW9odTsgSGltYW5zaHUgQy4gU2hhaDsgWHV4 aWFvaHU7IEhpbWFuc2h1IFNoYWg7DQo+IExpemhlbmJpbg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LXNwcmluZy1zZmMtdXNlLWNhc2UtMDEudHh0DQo+ IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXh1LXNwcmluZy1zZmMtdXNlLWNh c2UtMDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC14 dS1zcHJpbmctc2ZjLXVzZS1jYXNlDQo+IFJldmlzaW9uOgkwMQ0KPiBUaXRsZToJCVNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcgVXNlIENhc2UgZm9yIFNQUklORw0KPiBEb2N1bWVudCBkYXRlOgky MDE0LTA2LTE4DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNg0K PiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LXNw cmluZy1zZmMtdXNlLWNhc2UtMDEudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1zcHJpbmctc2ZjLXVzZS1jYXNlLw0KPiBIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXNm Yy11c2UtY2FzZS0wMQ0KPiBEaWZmOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC14dS1zcHJpbmctc2ZjLXVzZS1jYXNlLTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBwYXJ0aWN1bGFyIHVzZSBjYXNlIGZvciBTUFJJTkcg d2hlcmUgdGhlDQo+ICAgIFNlZ21lbnQgUm91dGluZyBtZWNoYW5pc20gaXMgbGV2ZXJhZ2VkIHRv IHJlYWxpemUgdGhlIHNlcnZpY2UgcGF0aA0KPiAgICBsYXllciBmdW5jdGlvbmFsaXR5IG9mIHRo ZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChpLmUsIHN0ZWVyaW5nDQo+ICAgIHRyYWZmaWMg dGhyb3VnaCB0aGUgc2VydmljZSBmdW5jdGlvbiBwYXRoKS4NCj4gDQo+IA0KPiANCj4gDQo+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== From nobody Tue Jun 17 23:58:39 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7B11A001A for ; Tue, 17 Jun 2014 23:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzdaVQJd8LpM for ; Tue, 17 Jun 2014 23:58:35 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FABF1A000C for ; Tue, 17 Jun 2014 23:58:35 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id r2so467032igi.0 for ; Tue, 17 Jun 2014 23:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iuErWVTQ2Tt8KN5pTvLlho8EzjoOZoDt9W/oBklF5cs=; b=diZ5UWtX6GuGhTBofwi/ymNKuDkCm87JZOiNpqIx0d1CWjivcH2c7c2a1tmRaW3Mgy +xPTnS8ar2OZjuNMsJWYuFOtbiY616hFWflBBrRik8n0k4Pj8ma3wut9AA/LCUVe/qBh LD2hLpZNfoldsv7E1CYe8klTXt0z7vtoyaWDsYj9fF6fKbaLi3HXI1ayQ4q1jvmcfZRv EB9JhieD2zOjB5TK91EIvnc/A1drjOMRyYhObBOp7VAmWFWIybrWxUA6hINpV4yw1C82 +/Dq5zafzrvtForT49Mo2FUGZEvP0/KC9Y11DKyAQp33BadA9cSUWHNqseushBfFxBGI +3Jg== MIME-Version: 1.0 X-Received: by 10.42.82.148 with SMTP id d20mr348087icl.97.1403074714765; Tue, 17 Jun 2014 23:58:34 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Tue, 17 Jun 2014 23:58:34 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> Date: Wed, 18 Jun 2014 08:58:34 +0200 X-Google-Sender-Auth: 0GPchMdIkCYAjhk_LJF9O9cygP8 Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/9nAds49TWO6oMMU1dXY5M68Uv_Y Cc: "" Subject: Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 06:58:36 -0000 Hello Xu, I have the following concern regarding your proposal. The draft says: In addition, they have allocated and advertised segment IDs (SID) for the service functions they are offering. For example, SN1 allocates and advertises an SID, i.e., SID(SF1) for service function SF1 while SN2 allocates and advertises an SID, i.e., SID(SF2) for service function SF2. However practically service function will never be global. Service function will in vast majority of practical services cases at least context based + customer based. So If you are going to allocate per customer context a SID it means that core network transport plane IGPs (which should be as lean as possible) now becomes very quickly polluted with a lot of customer information and customer state. Without that you need to describe on what other fields SR SF nodes may demux incoming traffic to different contexts. My personal preference would be to keep all of this per customer application service info outside of IGPs (no matter how well they can scale today). Best regards, R. On Wed, Jun 18, 2014 at 4:28 AM, Xuxiaohu wrote: > Hi all, > > This document describes a service function chaining use case for SPRING. Any comments are welcome. > > Best regards, > Xiaohu/Robin/Himanshu From nobody Wed Jun 18 00:50:18 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA911A00A6 for ; Wed, 18 Jun 2014 00:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 277-2jYN8H5l for ; Wed, 18 Jun 2014 00:50:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E661A0092 for ; Wed, 18 Jun 2014 00:50:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFN97862; Wed, 18 Jun 2014 07:50:10 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 08:50:08 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 15:50:03 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt Thread-Index: AQHPipxuOL+tsueljkWKFZ07diYiIJt2I8FA///GWgCAAI1AQA== Date: Wed, 18 Jun 2014 07:50:02 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082830C8@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/FvnEVZ44gtHoE_XCcqlk5rPjLdc Cc: "" Subject: Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 07:50:16 -0000 SGkgUm9iZXJ0LA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUg bXkgcmVzcG9uc2UgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFs ZiBPZiBSb2JlcnQNCj4gUmFzenVrDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxOCwgMjAxNCAy OjU5IFBNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzogPHNwcmluZ0BpZXRmLm9yZz4NCj4gU3ViamVj dDogUmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0 LXh1LXNwcmluZy1zZmMtdXNlLWNhc2UtMDEudHh0DQo+IA0KPiBIZWxsbyBYdSwNCj4gDQo+IEkg aGF2ZSB0aGUgZm9sbG93aW5nIGNvbmNlcm4gcmVnYXJkaW5nIHlvdXIgcHJvcG9zYWwuDQo+IA0K PiBUaGUgZHJhZnQgc2F5czoNCj4gDQo+ICAgIEluIGFkZGl0aW9uLCB0aGV5IGhhdmUgYWxsb2Nh dGVkIGFuZCBhZHZlcnRpc2VkDQo+ICAgIHNlZ21lbnQgSURzIChTSUQpIGZvciB0aGUgc2Vydmlj ZSBmdW5jdGlvbnMgdGhleSBhcmUgb2ZmZXJpbmcuICBGb3INCj4gICAgZXhhbXBsZSwgU04xIGFs bG9jYXRlcyBhbmQgYWR2ZXJ0aXNlcyBhbiBTSUQsIGkuZS4sIFNJRChTRjEpIGZvcg0KPiAgICBz ZXJ2aWNlIGZ1bmN0aW9uIFNGMSB3aGlsZSBTTjIgYWxsb2NhdGVzIGFuZCBhZHZlcnRpc2VzIGFu IFNJRCwgaS5lLiwNCj4gICAgU0lEKFNGMikgZm9yIHNlcnZpY2UgZnVuY3Rpb24gU0YyLg0KPiAN Cj4gDQo+IEhvd2V2ZXIgcHJhY3RpY2FsbHkgc2VydmljZSBmdW5jdGlvbiB3aWxsIG5ldmVyIGJl IGdsb2JhbC4gU2VydmljZSBmdW5jdGlvbiB3aWxsIGluDQo+IHZhc3QgbWFqb3JpdHkgb2YgcHJh Y3RpY2FsIHNlcnZpY2VzIGNhc2VzIGF0IGxlYXN0IGNvbnRleHQgYmFzZWQgKyBjdXN0b21lciBi YXNlZC4NCg0KU2VydmljZSBmdW5jdGlvbiAoU0YpIFNJRHMgYXJlIGxvY2FsbHkgc2lnbmlmaWNh bnQuIEluIHRoZSBNUExTLVNSIGNhc2UsIHRoZSBTRiBTSURzIGFyZSBqdXN0IGxvY2FsIE1QTFMg bGFiZWxzLiBCZXNpZGVzIHRoZSBTRiBTSUQsIGVhY2ggU0Ygd291bGQgaGF2ZSBhbiBTRiBJRCB3 aGljaCBpcyB1bmlxdWUgd2l0aGluIHRoZSBTRkMtZW5hYmxlZCBkb21haW4uIFRoZXJlZm9yZSwg ZWFjaCBzZXJ2aWNlIG5vZGUgd2hpY2ggaXMgb2ZmZXJpbmcgYSBnaXZlbiBTRiBuZWVkcyB0byBh bGxvY2F0ZSBhIGxvY2FsbHkgc2lnbmlmaWNhbnQgU0YgU0lEIChlLmcuLCBhbiBNUExTIGxhYmVs KSBmb3IgdGhhdCBTRiBhbmQgdGhlbiBhZHZlcnRpc2UgaXQgKHNlZSBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC14dS1vc3BmLXNlcnZpY2UtZnVuY3Rpb24tYWR2LTAxKS4NCg0KPiBT byBJZiB5b3UgYXJlIGdvaW5nIHRvIGFsbG9jYXRlIHBlciBjdXN0b21lciBjb250ZXh0IGEgU0lE IGl0IG1lYW5zIHRoYXQgY29yZQ0KPiBuZXR3b3JrIHRyYW5zcG9ydCBwbGFuZSBJR1BzICh3aGlj aCBzaG91bGQgYmUgYXMgbGVhbiBhcw0KPiBwb3NzaWJsZSkgbm93IGJlY29tZXMgdmVyeSBxdWlj a2x5IHBvbGx1dGVkIHdpdGggYSBsb3Qgb2YgY3VzdG9tZXIgaW5mb3JtYXRpb24NCj4gYW5kIGN1 c3RvbWVyIHN0YXRlLg0KDQpXaHkgZG9lcyB0aGUgU0YgU0lEIG5lZWQgdG8gYmUgb24gdGhlIGJh c2lzIG9mIHBlciBjdXN0b21lciBjb250ZXh0PyBTaG91bGRuJ3QgdGhlIGN1c3RvbWVyIGNvbnRl eHQgYmUgY2FycmllZCBzb21ld2hlcmUgZWxzZSAoZS5nLiwgaW4gdGhlIFNGQyBtZXRhZGF0YSku IFNlZSB0aGUgZm9sbG93aW5nIHRleHQgcXVvdGVkIGZyb20gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC0wMiNwYWdlLTkpIA0KDQogICBOZXR3b3JrIHNoYXJl ZCBjb250ZXh0OiBtZXRhZGF0YSByZWxldmFudCB0byBhbnkgbmV0d29yayBub2RlIHN1Y2ggYXMN CiAgIHRoZSByZXN1bHQgb2YgZWRnZSBjbGFzc2lmaWNhdGlvbi4gIEZvciBleGFtcGxlLCBhcHBs aWNhdGlvbg0KICAgaW5mb3JtYXRpb24sIGlkZW50aXR5IGluZm9ybWF0aW9uIG9yIHRlbmFuY3kg aW5mb3JtYXRpb24gY2FuIGJlDQogICBzaGFyZWQgdXNpbmcgdGhpcyBjb250ZXh0IGhlYWRlci4N Cg0KPiBXaXRob3V0IHRoYXQgeW91IG5lZWQgdG8gZGVzY3JpYmUgb24gd2hhdCBvdGhlciBmaWVs ZHMgU1IgU0Ygbm9kZXMgbWF5IGRlbXV4DQo+IGluY29taW5nIHRyYWZmaWMgdG8gZGlmZmVyZW50 IGNvbnRleHRzLg0KPiANCj4gTXkgcGVyc29uYWwgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBrZWVw IGFsbCBvZiB0aGlzIHBlciBjdXN0b21lciBhcHBsaWNhdGlvbg0KPiBzZXJ2aWNlIGluZm8gb3V0 c2lkZSBvZiBJR1BzIChubyBtYXR0ZXIgaG93IHdlbGwgdGhleSBjYW4gc2NhbGUgdG9kYXkpLg0K DQpJZiB5b3UgZG9uJ3Qgd2FudCB0byB1c2UgSUdQIHRvIHJlYWxpemUgdGhlIHNlcnZpY2UgZnVu Y3Rpb24gYXV0by1kaXNjb3ZlcnksIHlvdSBjYW4gdXNlIG90aGVyIGF1dG8tZGlzY292ZXJ5IG1l Y2hhbmlzbXMsIGUuZy4sIEROUy4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gQmVzdCBy ZWdhcmRzLA0KPiBSLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiBXZWQsIEp1biAxOCwg MjAxNCBhdCA0OjI4IEFNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ ID4gSGkgYWxsLA0KPiA+DQo+ID4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWluaW5nIHVzZSBjYXNlIGZvciBTUFJJTkcuIEFueQ0KPiBjb21tZW50cyBhcmUg d2VsY29tZS4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUvUm9iaW4vSGltYW5z aHUNCg== From nobody Wed Jun 18 05:05:40 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE38C1A01D3 for ; Wed, 18 Jun 2014 05:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MANGLED_SIDE=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnw1-OgPOiSU for ; Wed, 18 Jun 2014 05:05:36 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E978F1A01D1 for ; Wed, 18 Jun 2014 05:05:35 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so595158ieb.36 for ; Wed, 18 Jun 2014 05:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nJZ9XTC40AGXlsY9Grm2YRacC4aXWqNC0dT3UdixMA4=; b=wZ8U9hAl1+7ktZLh1EJtOdVZ42LuevfadM0NGUsT2eSbPEbb2BxmFFVE6sUR8/kXxj VXiKhH1GxGdlgOE9Nwx7N4hzFg5AX8NQkLwnDwG+SF4WTPPnPIruoppCgQeN+KJLFKP/ 54iGEmvhkjT4O277/g9xoyhb1Rqs0iZNubNHln9rd3QsxyNzaGTBNqAZFjksweN8ZuAj x7wCsgd2oQrcTy5W35mK0c6Lxlx6aHysWsuOfqHF6o0wqvtb5Xpa6whUqw5EN16+4cSS iedTFoEUB6DjP0NTdH8cefPDNqkAUBMq4NKiOxcmZqMGDAWQLVjfdBsMk/cvtCznxvdd 5cdA== MIME-Version: 1.0 X-Received: by 10.42.82.148 with SMTP id d20mr1569542icl.97.1403093135404; Wed, 18 Jun 2014 05:05:35 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 18 Jun 2014 05:05:35 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082830C8@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082830C8@NKGEML512-MBS.china.huawei.com> Date: Wed, 18 Jun 2014 14:05:35 +0200 X-Google-Sender-Auth: mmREzjt9EzoJMV43krcCh18qyiE Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/spring/fi_qOllFN6m7m1NrstQFF4ZgARk Cc: "" Subject: Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 12:05:37 -0000 Xu, If you do not demux based on the segment ID to a particular service context (and do that based on external information like metadata) then your set of documents brings really nothing new and it just renames Segment Node to be also called Service Node with bunch of new terminology. Therefor I do question need for this set of new drafts. Best, R. On Wed, Jun 18, 2014 at 9:50 AM, Xuxiaohu wrote: > Hi Robert, > > Thanks a lot for your comments. Please see my response inline. > >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Wednesday, June 18, 2014 2:59 PM >> To: Xuxiaohu >> Cc: >> Subject: Re: [spring] FW: New Version Notification for >> draft-xu-spring-sfc-use-case-01.txt >> >> Hello Xu, >> >> I have the following concern regarding your proposal. >> >> The draft says: >> >> In addition, they have allocated and advertised >> segment IDs (SID) for the service functions they are offering. For >> example, SN1 allocates and advertises an SID, i.e., SID(SF1) for >> service function SF1 while SN2 allocates and advertises an SID, i.e., >> SID(SF2) for service function SF2. >> >> >> However practically service function will never be global. Service funct= ion will in >> vast majority of practical services cases at least context based + custo= mer based. > > Service function (SF) SIDs are locally significant. In the MPLS-SR case, = the SF SIDs are just local MPLS labels. Besides the SF SID, each SF would h= ave an SF ID which is unique within the SFC-enabled domain. Therefore, each= service node which is offering a given SF needs to allocate a locally sign= ificant SF SID (e.g., an MPLS label) for that SF and then advertise it (see= http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-01). > >> So If you are going to allocate per customer context a SID it means that= core >> network transport plane IGPs (which should be as lean as >> possible) now becomes very quickly polluted with a lot of customer infor= mation >> and customer state. > > Why does the SF SID need to be on the basis of per customer context? Shou= ldn't the customer context be carried somewhere else (e.g., in the SFC meta= data). See the following text quoted from http://tools.ietf.org/html/draft-= quinn-sfc-nsh-02#page-9) > > Network shared context: metadata relevant to any network node such as > the result of edge classification. For example, application > information, identity information or tenancy information can be > shared using this context header. > >> Without that you need to describe on what other fields SR SF nodes may d= emux >> incoming traffic to different contexts. >> >> My personal preference would be to keep all of this per customer applica= tion >> service info outside of IGPs (no matter how well they can scale today). > > If you don't want to use IGP to realize the service function auto-discove= ry, you can use other auto-discovery mechanisms, e.g., DNS. > > Best regards, > Xiaohu > >> Best regards, >> R. >> >> >> >> >> >> >> On Wed, Jun 18, 2014 at 4:28 AM, Xuxiaohu wrote: >> > Hi all, >> > >> > This document describes a service function chaining use case for SPRIN= G. Any >> comments are welcome. >> > >> > Best regards, >> > Xiaohu/Robin/Himanshu > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jun 18 18:22:20 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458C41A01F6 for ; Wed, 18 Jun 2014 18:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCIDSuoB0KNg for ; Wed, 18 Jun 2014 18:22:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D751A01BF for ; Wed, 18 Jun 2014 18:22:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO72893; Thu, 19 Jun 2014 01:22:11 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 02:22:10 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 19 Jun 2014 09:22:06 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt Thread-Index: AQHPipxuOL+tsueljkWKFZ07diYiIJt2I8FA///GWgCAAI1AQP//yIiAgAFjC1A= Date: Thu, 19 Jun 2014 01:22:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082833F7@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082830C8@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/e6_3O785Ge9rn_P0wLu9c8JZuVA Cc: "" Subject: Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 01:22:17 -0000 Hi Robert, > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Robert Raszuk > Sent: Wednesday, June 18, 2014 8:06 PM > To: Xuxiaohu > Cc: > Subject: Re: [spring] FW: New Version Notification for > draft-xu-spring-sfc-use-case-01.txt >=20 > Xu, >=20 > If you do not demux based on the segment ID to a particular service conte= xt > (and do that based on external information like metadata) then your set o= f > documents brings really nothing new and it just renames Segment Node to b= e > also called Service Node with bunch of new terminology. The locally significant Service Function SID is used to indicate a particul= ar service function instance on a given service node (see http://tools.ietf= .org/html/draft-xu-isis-service-function-adv-01). The service node itself i= s indicated by a node SID (this is not new). Best regards, Xiaohu > Therefor I do question need for this set of new drafts. >=20 > Best, > R. >=20 >=20 >=20 >=20 >=20 > On Wed, Jun 18, 2014 at 9:50 AM, Xuxiaohu wrote: > > Hi Robert, > > > > Thanks a lot for your comments. Please see my response inline. > > > >> -----Original Message----- > >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of > >> Robert Raszuk > >> Sent: Wednesday, June 18, 2014 2:59 PM > >> To: Xuxiaohu > >> Cc: > >> Subject: Re: [spring] FW: New Version Notification for > >> draft-xu-spring-sfc-use-case-01.txt > >> > >> Hello Xu, > >> > >> I have the following concern regarding your proposal. > >> > >> The draft says: > >> > >> In addition, they have allocated and advertised > >> segment IDs (SID) for the service functions they are offering. For > >> example, SN1 allocates and advertises an SID, i.e., SID(SF1) for > >> service function SF1 while SN2 allocates and advertises an SID, i.e= ., > >> SID(SF2) for service function SF2. > >> > >> > >> However practically service function will never be global. Service > >> function will in vast majority of practical services cases at least co= ntext based > + customer based. > > > > Service function (SF) SIDs are locally significant. In the MPLS-SR case= , the SF > SIDs are just local MPLS labels. Besides the SF SID, each SF would have a= n SF ID > which is unique within the SFC-enabled domain. Therefore, each service no= de > which is offering a given SF needs to allocate a locally significant SF S= ID (e.g., an > MPLS label) for that SF and then advertise it (see > http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-01). > > > >> So If you are going to allocate per customer context a SID it means > >> that core network transport plane IGPs (which should be as lean as > >> possible) now becomes very quickly polluted with a lot of customer > >> information and customer state. > > > > Why does the SF SID need to be on the basis of per customer context? > > Shouldn't the customer context be carried somewhere else (e.g., in the > > SFC metadata). See the following text quoted from > > http://tools.ietf.org/html/draft-quinn-sfc-nsh-02#page-9) > > > > Network shared context: metadata relevant to any network node such a= s > > the result of edge classification. For example, application > > information, identity information or tenancy information can be > > shared using this context header. > > > >> Without that you need to describe on what other fields SR SF nodes > >> may demux incoming traffic to different contexts. > >> > >> My personal preference would be to keep all of this per customer > >> application service info outside of IGPs (no matter how well they can = scale > today). > > > > If you don't want to use IGP to realize the service function auto-disco= very, you > can use other auto-discovery mechanisms, e.g., DNS. > > > > Best regards, > > Xiaohu > > > >> Best regards, > >> R. > >> > >> > >> > >> > >> > >> > >> On Wed, Jun 18, 2014 at 4:28 AM, Xuxiaohu > wrote: > >> > Hi all, > >> > > >> > This document describes a service function chaining use case for > >> > SPRING. Any > >> comments are welcome. > >> > > >> > Best regards, > >> > Xiaohu/Robin/Himanshu > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jun 18 23:00:16 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C151A0344 for ; Wed, 18 Jun 2014 23:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MANGLED_SIDE=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kNV3DmamWeL for ; Wed, 18 Jun 2014 23:00:00 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4521A0172 for ; Wed, 18 Jun 2014 22:59:59 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id tr6so1637007ieb.15 for ; Wed, 18 Jun 2014 22:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=d6Bmagbv5qI/I0YVQyNAJ9Mvy8ewBh5NeXp2PFU/oUI=; b=vE+sW6DZJmvMqDB0vT3si5dUEgX4dGqTbPp9MVyFBksJ9vG2o4hFrfqHoTud437kwJ 2El10XjVZTs7+sRBl0nFwLgxtlQJ9vcJzA9TLAyQaGtK4mxT3fP2NgTSfmZfGN1CEU1r aNC6JvU3engYYrpLLZGAi6aA5psLuvTlvHiYwHNnKkWfLfBeltWhzsMEgaQWw4AT6dHJ +RY7ZBEz2ARZp5TG2dHweHtIJV4W5bZtSfWzt5893siLfyfAyK3tMpocBUDQ09FDRA0f IFEVe7v1STcOwYXytFb9BFXIeiFaR0v3Y/0uqp1EltLztLDRBw/YQfewXlE3t4hmtd77 qNHg== MIME-Version: 1.0 X-Received: by 10.50.62.40 with SMTP id v8mr4710125igr.21.1403157599278; Wed, 18 Jun 2014 22:59:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 18 Jun 2014 22:59:58 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082833F7@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082830C8@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082833F7@NKGEML512-MBS.china.huawei.com> Date: Thu, 19 Jun 2014 07:59:58 +0200 X-Google-Sender-Auth: H-KuCSMHrOABs1gBkp5BfPPBuqY Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/spring/xKKnWhDAUQGphNJH1p3l8TJNhFg Cc: "" Subject: Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 06:00:03 -0000 Hi Xu, As far as I can see there is no limitation in SR architecture that service node must be a physical device or that its definition is limited to be global per device. Therefor it seems easy to define where needed virtual service node with its SID or SIDs to indicate its different role in the network (that includes functional role) even if this is all on the same device. The benefit for me is clear - to avoid new protocol extensions required for what you call SFC use case. Less complexity is always good. Best, R. On Thu, Jun 19, 2014 at 3:22 AM, Xuxiaohu wrote: > Hi Robert, > >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Robert Raszuk >> Sent: Wednesday, June 18, 2014 8:06 PM >> To: Xuxiaohu >> Cc: >> Subject: Re: [spring] FW: New Version Notification for >> draft-xu-spring-sfc-use-case-01.txt >> >> Xu, >> >> If you do not demux based on the segment ID to a particular service cont= ext >> (and do that based on external information like metadata) then your set = of >> documents brings really nothing new and it just renames Segment Node to = be >> also called Service Node with bunch of new terminology. > > The locally significant Service Function SID is used to indicate a partic= ular service function instance on a given service node (see http://tools.ie= tf.org/html/draft-xu-isis-service-function-adv-01). The service node itself= is indicated by a node SID (this is not new). > > Best regards, > Xiaohu > >> Therefor I do question need for this set of new drafts. >> >> Best, >> R. >> >> >> >> >> >> On Wed, Jun 18, 2014 at 9:50 AM, Xuxiaohu wrote: >> > Hi Robert, >> > >> > Thanks a lot for your comments. Please see my response inline. >> > >> >> -----Original Message----- >> >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of >> >> Robert Raszuk >> >> Sent: Wednesday, June 18, 2014 2:59 PM >> >> To: Xuxiaohu >> >> Cc: >> >> Subject: Re: [spring] FW: New Version Notification for >> >> draft-xu-spring-sfc-use-case-01.txt >> >> >> >> Hello Xu, >> >> >> >> I have the following concern regarding your proposal. >> >> >> >> The draft says: >> >> >> >> In addition, they have allocated and advertised >> >> segment IDs (SID) for the service functions they are offering. Fo= r >> >> example, SN1 allocates and advertises an SID, i.e., SID(SF1) for >> >> service function SF1 while SN2 allocates and advertises an SID, i.= e., >> >> SID(SF2) for service function SF2. >> >> >> >> >> >> However practically service function will never be global. Service >> >> function will in vast majority of practical services cases at least c= ontext based >> + customer based. >> > >> > Service function (SF) SIDs are locally significant. In the MPLS-SR cas= e, the SF >> SIDs are just local MPLS labels. Besides the SF SID, each SF would have = an SF ID >> which is unique within the SFC-enabled domain. Therefore, each service n= ode >> which is offering a given SF needs to allocate a locally significant SF = SID (e.g., an >> MPLS label) for that SF and then advertise it (see >> http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-01). >> > >> >> So If you are going to allocate per customer context a SID it means >> >> that core network transport plane IGPs (which should be as lean as >> >> possible) now becomes very quickly polluted with a lot of customer >> >> information and customer state. >> > >> > Why does the SF SID need to be on the basis of per customer context? >> > Shouldn't the customer context be carried somewhere else (e.g., in the >> > SFC metadata). See the following text quoted from >> > http://tools.ietf.org/html/draft-quinn-sfc-nsh-02#page-9) >> > >> > Network shared context: metadata relevant to any network node such = as >> > the result of edge classification. For example, application >> > information, identity information or tenancy information can be >> > shared using this context header. >> > >> >> Without that you need to describe on what other fields SR SF nodes >> >> may demux incoming traffic to different contexts. >> >> >> >> My personal preference would be to keep all of this per customer >> >> application service info outside of IGPs (no matter how well they can= scale >> today). >> > >> > If you don't want to use IGP to realize the service function auto-disc= overy, you >> can use other auto-discovery mechanisms, e.g., DNS. >> > >> > Best regards, >> > Xiaohu >> > >> >> Best regards, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jun 18, 2014 at 4:28 AM, Xuxiaohu >> wrote: >> >> > Hi all, >> >> > >> >> > This document describes a service function chaining use case for >> >> > SPRING. Any >> >> comments are welcome. >> >> > >> >> > Best regards, >> >> > Xiaohu/Robin/Himanshu >> > _______________________________________________ >> > spring mailing list >> > spring@ietf.org >> > https://www.ietf.org/mailman/listinfo/spring >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jun 18 23:17:39 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7BD1A0260 for ; Wed, 18 Jun 2014 23:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5F0mXLRvrWm for ; Wed, 18 Jun 2014 23:17:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE891A0172 for ; Wed, 18 Jun 2014 23:17:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIP00148; Thu, 19 Jun 2014 06:17:32 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 07:17:18 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 19 Jun 2014 14:17:11 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt Thread-Index: AQHPipxuOL+tsueljkWKFZ07diYiIJt2I8FA///GWgCAAI1AQP//yIiAgAFjC1D//8kjAAAQ+1sQ Date: Thu, 19 Jun 2014 06:17:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082834F4@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082830C8@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082833F7@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/OecE4Ci1VIRgtPCR-wPVmjtn6_Y Cc: "" Subject: Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 06:17:38 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcnJhc3p1a0BnbWFpbC5j b20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydA0KPiBSYXN6 dWsNCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMTksIDIwMTQgMjowMCBQTQ0KPiBUbzogWHV4aWFv aHUNCj4gQ2M6IDxzcHJpbmdAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC14dS1zcHJpbmctc2ZjLXVzZS1j YXNlLTAxLnR4dA0KPiANCj4gSGkgWHUsDQo+IA0KPiBBcyBmYXIgYXMgSSBjYW4gc2VlIHRoZXJl IGlzIG5vIGxpbWl0YXRpb24gaW4gU1IgYXJjaGl0ZWN0dXJlIHRoYXQgc2VydmljZSBub2RlIG11 c3QNCj4gYmUgYSBwaHlzaWNhbCBkZXZpY2Ugb3IgdGhhdCBpdHMgZGVmaW5pdGlvbiBpcyBsaW1p dGVkIHRvIGJlIGdsb2JhbCBwZXIgZGV2aWNlLg0KDQpJdCBkb2Vzbid0IGFzc3VtZSB0aGF0IHNl cnZpY2Ugbm9kZXMgbXVzdCBiZSBwaHlzaWNhbCBkZXZpY2VzIGF0IGFsbC4gSSBkb24ndCBrbm93 IHdoYXQgeW91IG1lYW50IGJ5IHNheWluZyAiIGJlIGdsb2JhbCBwZXIgZGV2aWNlICIuDQoNCj4g VGhlcmVmb3IgaXQgc2VlbXMgZWFzeSB0byBkZWZpbmUgd2hlcmUgbmVlZGVkIHZpcnR1YWwgc2Vy dmljZSBub2RlIHdpdGggaXRzIFNJRA0KPiBvciBTSURzIHRvIGluZGljYXRlIGl0cyBkaWZmZXJl bnQgcm9sZSBpbiB0aGUgbmV0d29yayAodGhhdCBpbmNsdWRlcyBmdW5jdGlvbmFsIHJvbGUpDQo+ IGV2ZW4gaWYgdGhpcyBpcyBhbGwgb24gdGhlIHNhbWUgZGV2aWNlLg0KDQpTdXJlLCBpdCBhbGxv d3MgbXVsdGlwbGUgc2VydmljZSBmdW5jdGlvbnMgYXJlIGxvY2F0ZWQgb24gdGhlIHNhbWUgZGV2 aWNlLg0KDQo+IFRoZSBiZW5lZml0IGZvciBtZSBpcyBjbGVhciAtIHRvIGF2b2lkIG5ldyBwcm90 b2NvbCBleHRlbnNpb25zIHJlcXVpcmVkIGZvciB3aGF0DQo+IHlvdSBjYWxsIFNGQyB1c2UgY2Fz ZS4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW50LiBXaXRob3V0IHByb3RvY29s IGV4dGVuc2lvbnMsIGhvdyBjb3VsZCBzZXJ2aWNlIGZ1bmN0aW9ucyBiZSBkaXNjb3ZlcmVkIGlu IG15IG1pbmQ/IA0KDQo+IExlc3MgY29tcGxleGl0eSBpcyBhbHdheXMgZ29vZC4NCg0KU3VyZS4N Cg0KQmVzdCByZWdhcmQsDQpYaWFvaHUNCg0KPiBCZXN0LA0KPiBSLg0KPiANCj4gDQo+IE9uIFRo dSwgSnVuIDE5LCAyMDE0IGF0IDM6MjIgQU0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29t PiB3cm90ZToNCj4gPiBIaSBSb2JlcnQsDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb2JlcnQNCj4gPj4gUmFzenVrDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwg SnVuZSAxOCwgMjAxNCA4OjA2IFBNDQo+ID4+IFRvOiBYdXhpYW9odQ0KPiA+PiBDYzogPHNwcmlu Z0BpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+ID4+IGRyYWZ0LXh1LXNwcmluZy1zZmMtdXNlLWNhc2UtMDEudHh0 DQo+ID4+DQo+ID4+IFh1LA0KPiA+Pg0KPiA+PiBJZiB5b3UgZG8gbm90IGRlbXV4IGJhc2VkIG9u IHRoZSBzZWdtZW50IElEIHRvIGEgcGFydGljdWxhciBzZXJ2aWNlDQo+ID4+IGNvbnRleHQgKGFu ZCBkbyB0aGF0IGJhc2VkIG9uIGV4dGVybmFsIGluZm9ybWF0aW9uIGxpa2UgbWV0YWRhdGEpDQo+ ID4+IHRoZW4geW91ciBzZXQgb2YgZG9jdW1lbnRzIGJyaW5ncyByZWFsbHkgbm90aGluZyBuZXcg YW5kIGl0IGp1c3QNCj4gPj4gcmVuYW1lcyBTZWdtZW50IE5vZGUgdG8gYmUgYWxzbyBjYWxsZWQg U2VydmljZSBOb2RlIHdpdGggYnVuY2ggb2YgbmV3DQo+IHRlcm1pbm9sb2d5Lg0KPiA+DQo+ID4g VGhlIGxvY2FsbHkgc2lnbmlmaWNhbnQgU2VydmljZSBGdW5jdGlvbiBTSUQgaXMgdXNlZCB0byBp bmRpY2F0ZSBhIHBhcnRpY3VsYXINCj4gc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSBvbiBhIGdp dmVuIHNlcnZpY2Ugbm9kZSAoc2VlDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXh1LWlzaXMtc2VydmljZS1mdW5jdGlvbi1hZHYtMDEpLiBUaGUgc2VydmljZQ0KPiBub2RlIGl0 c2VsZiBpcyBpbmRpY2F0ZWQgYnkgYSBub2RlIFNJRCAodGhpcyBpcyBub3QgbmV3KS4NCj4gPg0K PiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiBUaGVyZWZvciBJIGRvIHF1 ZXN0aW9uIG5lZWQgZm9yIHRoaXMgc2V0IG9mIG5ldyBkcmFmdHMuDQo+ID4+DQo+ID4+IEJlc3Qs DQo+ID4+IFIuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIFdlZCwgSnVu IDE4LCAyMDE0IGF0IDk6NTAgQU0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPiB3 cm90ZToNCj4gPj4gPiBIaSBSb2JlcnQsDQo+ID4+ID4NCj4gPj4gPiBUaGFua3MgYSBsb3QgZm9y IHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0KPiA+PiA+DQo+ ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IHJyYXN6dWtA Z21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZg0KPiA+PiA+ PiBSb2JlcnQgUmFzenVrDQo+ID4+ID4+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxOCwgMjAxNCAy OjU5IFBNDQo+ID4+ID4+IFRvOiBYdXhpYW9odQ0KPiA+PiA+PiBDYzogPHNwcmluZ0BpZXRmLm9y Zz4NCj4gPj4gPj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+ID4+ID4+IGRyYWZ0LXh1LXNwcmluZy1zZmMtdXNlLWNhc2UtMDEudHh0DQo+ ID4+ID4+DQo+ID4+ID4+IEhlbGxvIFh1LA0KPiA+PiA+Pg0KPiA+PiA+PiBJIGhhdmUgdGhlIGZv bGxvd2luZyBjb25jZXJuIHJlZ2FyZGluZyB5b3VyIHByb3Bvc2FsLg0KPiA+PiA+Pg0KPiA+PiA+ PiBUaGUgZHJhZnQgc2F5czoNCj4gPj4gPj4NCj4gPj4gPj4gICAgSW4gYWRkaXRpb24sIHRoZXkg aGF2ZSBhbGxvY2F0ZWQgYW5kIGFkdmVydGlzZWQNCj4gPj4gPj4gICAgc2VnbWVudCBJRHMgKFNJ RCkgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGV5IGFyZSBvZmZlcmluZy4gIEZvcg0KPiA+ PiA+PiAgICBleGFtcGxlLCBTTjEgYWxsb2NhdGVzIGFuZCBhZHZlcnRpc2VzIGFuIFNJRCwgaS5l LiwgU0lEKFNGMSkgZm9yDQo+ID4+ID4+ICAgIHNlcnZpY2UgZnVuY3Rpb24gU0YxIHdoaWxlIFNO MiBhbGxvY2F0ZXMgYW5kIGFkdmVydGlzZXMgYW4gU0lELCBpLmUuLA0KPiA+PiA+PiAgICBTSUQo U0YyKSBmb3Igc2VydmljZSBmdW5jdGlvbiBTRjIuDQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+ IEhvd2V2ZXIgcHJhY3RpY2FsbHkgc2VydmljZSBmdW5jdGlvbiB3aWxsIG5ldmVyIGJlIGdsb2Jh bC4gU2VydmljZQ0KPiA+PiA+PiBmdW5jdGlvbiB3aWxsIGluIHZhc3QgbWFqb3JpdHkgb2YgcHJh Y3RpY2FsIHNlcnZpY2VzIGNhc2VzIGF0DQo+ID4+ID4+IGxlYXN0IGNvbnRleHQgYmFzZWQNCj4g Pj4gKyBjdXN0b21lciBiYXNlZC4NCj4gPj4gPg0KPiA+PiA+IFNlcnZpY2UgZnVuY3Rpb24gKFNG KSBTSURzIGFyZSBsb2NhbGx5IHNpZ25pZmljYW50LiBJbiB0aGUgTVBMUy1TUg0KPiA+PiA+IGNh c2UsIHRoZSBTRg0KPiA+PiBTSURzIGFyZSBqdXN0IGxvY2FsIE1QTFMgbGFiZWxzLiBCZXNpZGVz IHRoZSBTRiBTSUQsIGVhY2ggU0Ygd291bGQNCj4gPj4gaGF2ZSBhbiBTRiBJRCB3aGljaCBpcyB1 bmlxdWUgd2l0aGluIHRoZSBTRkMtZW5hYmxlZCBkb21haW4uDQo+ID4+IFRoZXJlZm9yZSwgZWFj aCBzZXJ2aWNlIG5vZGUgd2hpY2ggaXMgb2ZmZXJpbmcgYSBnaXZlbiBTRiBuZWVkcyB0bw0KPiA+ PiBhbGxvY2F0ZSBhIGxvY2FsbHkgc2lnbmlmaWNhbnQgU0YgU0lEIChlLmcuLCBhbiBNUExTIGxh YmVsKSBmb3IgdGhhdA0KPiA+PiBTRiBhbmQgdGhlbiBhZHZlcnRpc2UgaXQgKHNlZQ0KPiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1vc3BmLXNlcnZpY2UtZnVuY3Rpb24tYWR2 LTAxKS4NCj4gPj4gPg0KPiA+PiA+PiBTbyBJZiB5b3UgYXJlIGdvaW5nIHRvIGFsbG9jYXRlIHBl ciBjdXN0b21lciBjb250ZXh0IGEgU0lEIGl0DQo+ID4+ID4+IG1lYW5zIHRoYXQgY29yZSBuZXR3 b3JrIHRyYW5zcG9ydCBwbGFuZSBJR1BzICh3aGljaCBzaG91bGQgYmUgYXMNCj4gPj4gPj4gbGVh biBhcw0KPiA+PiA+PiBwb3NzaWJsZSkgbm93IGJlY29tZXMgdmVyeSBxdWlja2x5IHBvbGx1dGVk IHdpdGggYSBsb3Qgb2YgY3VzdG9tZXINCj4gPj4gPj4gaW5mb3JtYXRpb24gYW5kIGN1c3RvbWVy IHN0YXRlLg0KPiA+PiA+DQo+ID4+ID4gV2h5IGRvZXMgdGhlIFNGIFNJRCBuZWVkIHRvIGJlIG9u IHRoZSBiYXNpcyBvZiBwZXIgY3VzdG9tZXIgY29udGV4dD8NCj4gPj4gPiBTaG91bGRuJ3QgdGhl IGN1c3RvbWVyIGNvbnRleHQgYmUgY2FycmllZCBzb21ld2hlcmUgZWxzZSAoZS5nLiwgaW4NCj4g Pj4gPiB0aGUgU0ZDIG1ldGFkYXRhKS4gU2VlIHRoZSBmb2xsb3dpbmcgdGV4dCBxdW90ZWQgZnJv bQ0KPiA+PiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gt MDIjcGFnZS05KQ0KPiA+PiA+DQo+ID4+ID4gICAgTmV0d29yayBzaGFyZWQgY29udGV4dDogbWV0 YWRhdGEgcmVsZXZhbnQgdG8gYW55IG5ldHdvcmsgbm9kZSBzdWNoDQo+IGFzDQo+ID4+ID4gICAg dGhlIHJlc3VsdCBvZiBlZGdlIGNsYXNzaWZpY2F0aW9uLiAgRm9yIGV4YW1wbGUsIGFwcGxpY2F0 aW9uDQo+ID4+ID4gICAgaW5mb3JtYXRpb24sIGlkZW50aXR5IGluZm9ybWF0aW9uIG9yIHRlbmFu Y3kgaW5mb3JtYXRpb24gY2FuIGJlDQo+ID4+ID4gICAgc2hhcmVkIHVzaW5nIHRoaXMgY29udGV4 dCBoZWFkZXIuDQo+ID4+ID4NCj4gPj4gPj4gV2l0aG91dCB0aGF0IHlvdSBuZWVkIHRvIGRlc2Ny aWJlIG9uIHdoYXQgb3RoZXIgZmllbGRzIFNSIFNGIG5vZGVzDQo+ID4+ID4+IG1heSBkZW11eCBp bmNvbWluZyB0cmFmZmljIHRvIGRpZmZlcmVudCBjb250ZXh0cy4NCj4gPj4gPj4NCj4gPj4gPj4g TXkgcGVyc29uYWwgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBrZWVwIGFsbCBvZiB0aGlzIHBlciBj dXN0b21lcg0KPiA+PiA+PiBhcHBsaWNhdGlvbiBzZXJ2aWNlIGluZm8gb3V0c2lkZSBvZiBJR1Bz IChubyBtYXR0ZXIgaG93IHdlbGwgdGhleQ0KPiA+PiA+PiBjYW4gc2NhbGUNCj4gPj4gdG9kYXkp Lg0KPiA+PiA+DQo+ID4+ID4gSWYgeW91IGRvbid0IHdhbnQgdG8gdXNlIElHUCB0byByZWFsaXpl IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uDQo+ID4+ID4gYXV0by1kaXNjb3ZlcnksIHlvdQ0KPiA+PiBj YW4gdXNlIG90aGVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbXMsIGUuZy4sIEROUy4NCj4gPj4g Pg0KPiA+PiA+IEJlc3QgcmVnYXJkcywNCj4gPj4gPiBYaWFvaHUNCj4gPj4gPg0KPiA+PiA+PiBC ZXN0IHJlZ2FyZHMsDQo+ID4+ID4+IFIuDQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+IE9uIFdlZCwgSnVuIDE4LCAyMDE0IGF0IDQ6 MjggQU0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4g Pj4gPiBIaSBhbGwsDQo+ID4+ID4+ID4NCj4gPj4gPj4gPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBhIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgdXNlIGNhc2UgZm9yDQo+ID4+ID4+ID4gU1BS SU5HLiBBbnkNCj4gPj4gPj4gY29tbWVudHMgYXJlIHdlbGNvbWUuDQo+ID4+ID4+ID4NCj4gPj4g Pj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4+ID4+ID4gWGlhb2h1L1JvYmluL0hpbWFuc2h1DQo+ID4+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4g PiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4+ID4gc3ByaW5nQGlldGYub3JnDQo+ID4+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCj4gPj4NCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gc3ByaW5n IG1haWxpbmcgbGlzdA0KPiA+PiBzcHJpbmdAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Wed Jun 18 23:23:48 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B514A1A024B for ; Wed, 18 Jun 2014 23:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o6gRcLrg5Ak for ; Wed, 18 Jun 2014 23:23:45 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02D31A0234 for ; Wed, 18 Jun 2014 23:23:45 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so1635529ier.2 for ; Wed, 18 Jun 2014 23:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=V+nx35DLan572yZlMz+bwGQSAgt6OEIk+ez0glNlDuQ=; b=YWFxKZMqceAqfyO83MPn3on6arMicW3CBTMN/TYXTOWM0RHBfAHZ0JMznFixlekuyl PmK5Kux2s5TrrM7eWfiEkD7i1fr1M8u2J8kKStTW64W51t7/N4p1uEer3RWlEu5urfQz fd9jINH/aqe1g8UtPj+xSKKjNtySAjMFWyh6ONc6v4WsW91JZGTKU9OUxY9HNkBZSCRX 6hVnHARG6ymn0OPn3XzgHewzcJMQoNkO3xsA69qJXOoiMP/JoNXkkvrIx6MImT8E2aor Q++0BeUdpFD7K/jP0aMfyN/Zu+SKJxmyVOf+PXnO7XieJoQSzmaOc8/NOR88pATdzYyb s5qQ== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr4857149igj.9.1403159025216; Wed, 18 Jun 2014 23:23:45 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 18 Jun 2014 23:23:45 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082834F4@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283015@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082830C8@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082833F7@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082834F4@NKGEML512-MBS.china.huawei.com> Date: Thu, 19 Jun 2014 08:23:45 +0200 X-Google-Sender-Auth: fgSPn_9MUlP6ufO28uDeDWOQLS0 Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/RI4EJRs_e_X0Efa0E1m3XJmD_1s Cc: "" Subject: Re: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 06:23:46 -0000 >> The benefit for me is clear - to avoid new protocol extensions required for what >> you call SFC use case. > > I don't understand what you meant. Without protocol extensions, how could > service functions be discovered in my mind? Via indirection. Do not flood those service functions in IGP. Just create mapping in the higher abstraction layer (for example in metadata) between service function and service nodes. Analogy to BGP next hop :) Otherwise we will be creating new protocol extensions and even new data plane type codes when base SR architecture can be used as is for it. Thx, r. From nobody Sun Jun 22 19:32:53 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35091B2856 for ; Sun, 22 Jun 2014 19:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQQntTPXLv4K for ; Sun, 22 Jun 2014 19:32:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59C81A03FB for ; Sun, 22 Jun 2014 19:32:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJA33624; Mon, 23 Jun 2014 02:32:48 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 03:32:47 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.190]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 23 Jun 2014 10:32:42 +0800 From: Youjianjie To: "" Thread-Topic: New Version Notification for draft-xu-spring-pce-based-sfc-arch-01.txt Thread-Index: AQHPjoXETBvlXj6nGECQlyeYgb9gNZt9+HfA Date: Mon, 23 Jun 2014 02:32:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/AVVtKtgwO6I58pbZm4tMa0VAwOc Subject: [spring] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-xu-spring-pce-based-sfc-arch-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:32:52 -0000 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGRlc2NyaWJlcyBhIFBDRS1iYXNlZCBTRkMgYXJjaGl0ZWN0 dXJlIGluIFNSIG5ldHdvcmtzLiBJbiB0aGlzIGFyY2hpdGVjdHVyZSwgdGhlIFBDRSBpcyB1c2Vk IHRvIGNvbXB1dGUgYSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggKFNGUCkuDQoNCllvdXIgY29tbWVu dHMgYXJlIGFwcHJlY2lhdGVkIQ0KDQpBdXRob3JzDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N CuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNOW5tDbmnIgyM+aXpSA5OjUyDQrmlLbk u7bkuro6IEx1aXMgTS4gQ29udHJlcmFzOyBYdXhpYW9odTsgWW91amlhbmppZTsgWHV4aWFvaHU7 IEhpbWFuc2h1IFNoYWg7IEhpbWFuc2h1IEMuIFNoYWg7IFlvdWppYW5qaWU7IEx1aXMgTS4gQ29u dHJlcmFzDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtc3By aW5nLXBjZS1iYXNlZC1zZmMtYXJjaC0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQteHUtc3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJjaC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gNClJl dmlzaW9uOgkwMQ0KVGl0bGU6CQlQQ0UtYmFzZWQgU0ZDIEFyY2hpdGVjdHVyZSBpbiBTUiBOZXR3 b3Jrcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNi0yMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1p c3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEudHh0DQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteHUt c3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJjaC8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1hcmNoLTAxDQpEaWZm OiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteHUtc3By aW5nLXBjZS1iYXNlZC1zZmMtYXJjaC0wMQ0KDQpBYnN0cmFjdDoNCiAgIFNlcnZpY2UgRnVuY3Rp b24gQ2hhaW5pbmcgKFNGQykgcHJvdmlkZXMgYSBmbGV4aWJsZSB3YXkgdG8gY29uc3RydWN0DQog ICBzZXJ2aWNlcy4gIFdoZW4gYXBwbHlpbmcgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgZnVuY3Rpb24g Y2hhaW4gdG8gdGhlDQogICB0cmFmZmljLCB0aGUgdHJhZmZpYyBuZWVkcyB0byBiZSBzdGVlcmVk IHRocm91Z2ggYW4gb3JkZXJlZCBzZXQgb2YNCiAgIHNlcnZpY2UgZnVuY3Rpb25zIGluIHRoZSBu ZXR3b3JrLiAgVGhpcyBvcmRlcmVkIHNldCBvZiBzZXJ2aWNlDQogICBmdW5jdGlvbnMgaW4gdGhl IG5ldHdvcmssIHJlZmVycmVkIHRvIGFzIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoDQogICAoU0ZQ KSwgaXMgYW4gaW5zdGFudGlhdGlvbiBvZiB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBpbiB0 aGUNCiAgIG5ldHdvcmsuICBTZWdtZW50IFJvdXRpbmcgKFNSKSB0ZWNobmlxdWUgY2FuIGJlIGxl dmVyYWdlZCB0byBzdGVlcg0KICAgdGhlIHRyYWZmaWMgdGhyb3VnaCB0aGUgU0ZQIGluIFNSIG5l dHdvcmtzLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMNCiAgIGEgUENFLWJhc2VkIFNGQyBhcmNo aXRlY3R1cmUgaW4gd2hpY2ggdGhlIFBDRSBpcyB1c2VkIHRvIGNvbXB1dGUgYQ0KICAgc2Vydmlj ZSBmdW5jdGlvbiBwYXRoIChpLmUuLCBpbnN0YW50aWF0ZSBhIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW4pIGluDQogICBTUiBuZXR3b3Jrcy4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From nobody Mon Jun 23 20:44:05 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091C41B2822; Mon, 23 Jun 2014 20:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU6A_0JG-Zyc; Mon, 23 Jun 2014 20:44:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07211B2820; Mon, 23 Jun 2014 20:43:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJC82429; Tue, 24 Jun 2014 03:43:58 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 04:43:55 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.190]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 11:43:49 +0800 From: Youjianjie To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-xu-spring-pce-based-sfc-arch-01.txt Thread-Index: AQHPjoXETBvlXj6nGECQlyeYgb9gNZt9+HfAgAGl/QA= Date: Tue, 24 Jun 2014 03:43:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/MXvxnlGHynx0-BFtuH-T2fXxVb8 Cc: "sfc@ietf.org" Subject: [spring] =?utf-8?b?562U5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-xu-spring-pce-based-sfc-arch-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 03:44:03 -0000 SGkgYWxsLA0KDQpUaGUgY29ycmVzcG9uZGluZyBleHRlbnNpb25zIHRvIHRoZSBQQ0VQIGluIHRo aXMgZHJhZnQgKGRyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEpIGFyZSBkZXNj cmliZWQgaW4gZHJhZnQteHUtcGNlLXNyLXNmYy0wMToNCg0KVVJMOiAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtcGNlLXNyLXNmYy0wMS50eHQg DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt eHUtcGNlLXNyLXNmYy8NCg0KQXMgYWx3YXlzLCB5b3VyIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRl ZCENCg0KSmlhbmppZQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHNwcmlu ZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggWW91amlhbmppZQ0K5Y+R 6YCB5pe26Ze0OiAyMDE05bm0NuaciDIz5pelIDEwOjMzDQrmlLbku7bkuro6IDxzcHJpbmdAaWV0 Zi5vcmc+DQrkuLvpopg6IFtzcHJpbmddIOi9rOWPkTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1hcmNoLTAxLnR4dA0KDQpIaSBhbGws DQoNClRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgUENFLWJhc2VkIFNGQyBhcmNoaXRlY3R1cmUgaW4g U1IgbmV0d29ya3MuIEluIHRoaXMgYXJjaGl0ZWN0dXJlLCB0aGUgUENFIGlzIHVzZWQgdG8gY29t cHV0ZSBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCAoU0ZQKS4NCg0KWW91ciBjb21tZW50cyBhcmUg YXBwcmVjaWF0ZWQhDQoNCkF1dGhvcnMNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu2 5Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0NuaciDIz5pelIDk6NTINCuaUtuS7tuS6ujog THVpcyBNLiBDb250cmVyYXM7IFh1eGlhb2h1OyBZb3VqaWFuamllOyBYdXhpYW9odTsgSGltYW5z aHUgU2hhaDsgSGltYW5zaHUgQy4gU2hhaDsgWW91amlhbmppZTsgTHVpcyBNLiBDb250cmVyYXMN CuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciB0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNm Yy1hcmNoDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJUENFLWJhc2VkIFNGQyBBcmNoaXRlY3R1cmUg aW4gU1IgTmV0d29ya3MNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMjINCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1hcmNo LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gvDQpIdG1saXplZDogICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJj aC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDENCg0KQWJzdHJhY3Q6DQogICBTZXJ2 aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIHByb3ZpZGVzIGEgZmxleGlibGUgd2F5IHRvIGNv bnN0cnVjdA0KICAgc2VydmljZXMuICBXaGVuIGFwcGx5aW5nIGEgcGFydGljdWxhciBzZXJ2aWNl IGZ1bmN0aW9uIGNoYWluIHRvIHRoZQ0KICAgdHJhZmZpYywgdGhlIHRyYWZmaWMgbmVlZHMgdG8g YmUgc3RlZXJlZCB0aHJvdWdoIGFuIG9yZGVyZWQgc2V0IG9mDQogICBzZXJ2aWNlIGZ1bmN0aW9u cyBpbiB0aGUgbmV0d29yay4gIFRoaXMgb3JkZXJlZCBzZXQgb2Ygc2VydmljZQ0KICAgZnVuY3Rp b25zIGluIHRoZSBuZXR3b3JrLCByZWZlcnJlZCB0byBhcyBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0 aA0KICAgKFNGUCksIGlzIGFuIGluc3RhbnRpYXRpb24gb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb24g Y2hhaW4gaW4gdGhlDQogICBuZXR3b3JrLiAgU2VnbWVudCBSb3V0aW5nIChTUikgdGVjaG5pcXVl IGNhbiBiZSBsZXZlcmFnZWQgdG8gc3RlZXINCiAgIHRoZSB0cmFmZmljIHRocm91Z2ggdGhlIFNG UCBpbiBTUiBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzDQogICBhIFBDRS1iYXNl ZCBTRkMgYXJjaGl0ZWN0dXJlIGluIHdoaWNoIHRoZSBQQ0UgaXMgdXNlZCB0byBjb21wdXRlIGEN CiAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCAoaS5lLiwgaW5zdGFudGlhdGUgYSBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWluKSBpbg0KICAgU1IgbmV0d29ya3MuDQoNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Thu Jun 26 06:10:46 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044E21B2C29; Thu, 26 Jun 2014 06:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKPWOflGxW7m; Thu, 26 Jun 2014 06:10:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D392D1B2FB4; Thu, 26 Jun 2014 06:09:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626130912.15326.15005.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 06:09:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/oO9MbhNaoXsHo3HvTgHVGOG_WRs Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-problem-statement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 13:10:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF. Title : SPRING Problem Statement and Requirements Authors : Stefano Previdi Clarence Filsfils Bruno Decraene Stephane Litkowski Martin Horneffer Ruediger Geib Rob Shakir Robert Raszuk Filename : draft-ietf-spring-problem-statement-01.txt Pages : 18 Date : 2014-06-26 Abstract: The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed'. This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use- cases and requirements are out of scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spring-problem-statement-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-spring-problem-statement-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 27 13:47:39 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8401A0118 for ; Fri, 27 Jun 2014 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWa5FTUjM3rP for ; Fri, 27 Jun 2014 13:47:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2951E1A0126 for ; Fri, 27 Jun 2014 13:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3756; q=dns/txt; s=iport; t=1403902050; x=1405111650; h=from:to:subject:date:message-id:mime-version; bh=m984RB9m/nSVGoxpkcI0ewZPuyLSvFwhgEsPmf8ynAs=; b=mbfX2DdsVwAGA+qctvTUdPAeXUqoDOx+ifxUIzPxwgXd4Xje39vI51XN wGiMWXtBxwKffiwVvD+ROrKbCndOi0fknOLO/eZhYmRCs1mV1WPZBy7hR wkUAy4YAog9eolGycd03F02QrA24w1N6zpbFHrgFee+ZUt//fkbqAhe9V w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoFACXXrVOtJV2Q/2dsb2JhbABaAYJGR1JaqkgBAQEBAQEFAQVoAZkCgQ4WdYQKZiUBDC0BAUUnBIhVDZgErEgTBIVkiR0uBAGEGwWaXZN7g0JsgUQ X-IronPort-AV: E=Sophos; i="5.01,563,1400025600"; d="scan'208,217"; a="56566198" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 27 Jun 2014 20:47:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5RKlTbg007059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Jun 2014 20:47:29 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.198]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 15:47:28 -0500 From: "Alvaro Retana (aretana)" To: "spring@ietf.org" Thread-Topic: IETF 90 Agenda Items (spring) Thread-Index: AQHPkkkCBrPwEfh1H0CrqIl+REriPw== Date: Fri, 27 Jun 2014 20:47:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CFD3509E5C8DFaretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/37wAiqNl2VMBZqg8Qc4e2IYVi5g Subject: [spring] IETF 90 Agenda Items (spring) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 20:47:33 -0000 --_000_CFD3509E5C8DFaretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We have a 2-hour slot in Toronto on Wednesday afternoon: WEDNESDAY, July 23, 2014 1300-1500 Afternoon Session I Canadian RTG spring Source Packet Routing in Networking WG Send any requests for time to John and I. We will prioritize the items alr= eady listed in the charter as milestones. Other items may be considered if = we have time. Please note that we will be requiring two conditions to be part of the fina= l agenda: (1) your draft MUST have been published already, and (2) you MUST= provide the chairs with your slides by EOD on Monday, July 21, 2014. We w= ill also appreciate starting a discussion on the list so everyone is aware = of your draft and/or any updates. Keep the following dates in mind: * 2014-07-04 (Friday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 23:59, upload using IETF ID Submission Tool. * 2014-07-07 (Monday): Draft Working Group agendas due by UTC 23:59, up= load using IETF Meeting Materials Management Tool. * 2014-07-14 (Monday): Revised Working Group agendas due by UTC 23:59, = upload using IETF Meeting Materials Management Tool. Thanks! Alvaro. --_000_CFD3509E5C8DFaretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <765C8AE2B40C854FA4C507F1610C25ED@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

We have a 2-hour slot in Toronto on Wednesday afternoon:
WEDNESDAY, July 23, 2014
1300-1500  Afternoon Session I
Canadian        RTG 	spring      Source Packet Routing in Networking WG

Send any requests for time to John and I.  We will prioritize the= items already listed in the charter as milestones. Other items may be cons= idered if we have time.

Please note that we will be requiring two conditions to be part of the= final agenda: (1) your draft MUST have been published already, and (2) you= MUST provide the chairs with your slides by EOD on Monday, July 21, 2014. =  We will also appreciate starting a discussion on the list so everyone is aware of your draft and/or any upd= ates.

Keep the following dates in mind:
Thanks!

Alvaro.
--_000_CFD3509E5C8DFaretanaciscocom_-- From nobody Mon Jun 30 13:25:56 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA511A0451 for ; Mon, 30 Jun 2014 13:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvfeH5BGD5VM for ; Mon, 30 Jun 2014 13:25:51 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BCF1A02FB for ; Mon, 30 Jun 2014 13:25:51 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so8730797wgg.27 for ; Mon, 30 Jun 2014 13:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=53kRKmB8cFy0rBe5t9GH5i9A1AqMXLH7fnonQ+2TbPY=; b=EmpgOqPUYaidF0hG01pCO4YUFE0DAexBS0zmhGHS6FqtjP3YuYVspjLpzylk+kx+FV Jl55XtI+hW0IGOmAVXs3iVENnCyvCoIxieNzn4jYzYHQfBuwRqSDrufIRP7rBdbPbxlh 8+R2w16jt8ytPabI8CZdxdTQbbSDIqakLgDQp+QZSPeWpTVwJhrktzoMO5dUBw+PvlEP P4s3YCR8suatnkvWxt0Pa4R3hnD9vSdhXNCORrZlduGtoiu5urG7R1GDbwBrtlbyvV5e tuYJTWZTy2s4EdOMe+0lC0QGe1GhRgZY7lriWzdOAQXTLsGuenI+rAa9htgdtP7zsXhz nfGA== MIME-Version: 1.0 X-Received: by 10.180.89.193 with SMTP id bq1mr31368060wib.81.1404159950033; Mon, 30 Jun 2014 13:25:50 -0700 (PDT) Received: by 10.216.139.132 with HTTP; Mon, 30 Jun 2014 13:25:49 -0700 (PDT) Date: Mon, 30 Jun 2014 16:25:49 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: spring@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3bb00107985504fd13770e Archived-At: http://mailarchive.ietf.org/arch/msg/spring/atkvCPyL7KMOCSVVtB3OJyzXHuE Subject: [spring] Fwd: draft-kh-spring-ip-ran-use-case-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:25:54 -0000 --e89a8f3bb00107985504fd13770e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All,Requesting review and comments on the following draft on Segment Routing in IP RAN use case. Thanks. =E2=80=8BBest. Bhumip Bhumip Khasnabish ++++++++++++++++++++++++++++++++++++++++++++++ I-D Action: draft-kh-spring-ip-ran-use-case-01.txt ------------------------------ - *To*: i-d-announce at ietf.org - *Subject*: I-D Action: draft-kh-spring-ip-ran-use-case-01.txt - *From*: internet-drafts at ietf.org - *Date*: Sun, 29 Jun 2014 20:20:15 -0700 - *Archived-at*: http://mailarchive.ietf.org/arch/msg/i-d-announce/91qgxSst6U3OI_W24E2u6y= hL8xs - *Auto-submitted*: auto-generated - *Delivered-to*: i-d-announce at ietfa.amsl.com - *List-archive*: - *List-help*: > - *List-id*: Internet Draft Announcements only - *List-post*: > - *List-subscribe*: = , > - *List-unsubscribe*: , > - *Reply-to*: internet-drafts at ietf.org ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Segment Routing in IP RAN use case Authors : Bhumip Khasnabish Fangwei Hu Filename : draft-kh-spring-ip-ran-use-case-01.txt Pages : 11 Date : 2014-06-29 Abstract: Segment Routing (SR) leverages the source routing paradigm. An ingress node steers a packet through a controlled set of instructions, called segments, by pre-pending the packet with an SR header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows one to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document introduces the segment routing in IP Radio Access Network (IP RAN, mobile backhaul network) use case. Additional requirements to support segment routing in the IP RAN scenarios are discussed. The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-kh-spring-ip-ran-use-case/ There's also a htmlized version available at:http://tools.ietf.org/html/draft-kh-spring-ip-ran-use-case-01 A diff from the previous version is available at:http://www.ietf.org/rfcdiff?url2=3Ddraft-kh-spring-ip-ran-use-case-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ =E2=80=8B =E2=80=8B --e89a8f3bb00107985504fd13770e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear All,

Requesting review and comments on the following draft on Segment= Routing in IP RAN use case. Thanks.

=E2=80=8BBest.

Bhumip

Bhumip Khasnabish
=C2=A0
++++++++++++++++++++++++++++++++++++++++++++++

I-D Action: draft-kh-spring-ip-ran-use-case-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


        Title           : Segment Routing in IP RAN use case
        Authors         : Bhumip Khasnabish
                          Fangwei Hu
	Filename        : draft-kh-spring-ip-ran-use-case-01.txt
	Pages           : 11
	Date            : 2014-06-29

Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  An
   ingress node steers a packet through a controlled set of
   instructions, called segments, by pre-pending the packet with an SR
   header.  A segment can represent any instruction, topological or
   service-based.  A segment can have a local semantic to an SR node or
   global within an SR domain.  SR allows one to enforce a flow through
   any topological path and service chain while maintaining per-flow
   state only at the ingress node of the SR domain.  This document
   introduces the segment routing in IP Radio Access Network (IP RAN,
   mobile backhaul network) use case.  Additional requirements to
   support segment routing in the IP RAN scenarios are discussed.


The IETF datatracker status page for this draft is:
https://datat=
racker.ietf.org/doc/draft-kh-spring-ip-ran-use-case/

There's also a htmlized version available at:
http://tools.ietf=
.org/html/draft-kh-spring-ip-ran-use-case-01

A diff from the previous version is available at:
http://ww=
w.ietf.org/rfcdiff?url2=3Ddraft-kh-spring-ip-ran-use-case-01


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<=
/a>

--e89a8f3bb00107985504fd13770e--