From nobody Tue Apr 1 04:51:19 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 EDE411A068C for ; Tue, 1 Apr 2014 04:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 yILJFtQ3pZK8 for ; Tue, 1 Apr 2014 04:51:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 485EF1A0683 for ; Tue, 1 Apr 2014 04:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1229; q=dns/txt; s=iport; t=1396353069; x=1397562669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N5qztaCEkXTfXvs95RCgBszRyckVqUo6uEzXzQd5U/A=; b=T8HbSUueXPHq6Ekz22DTCsAPoOYVP1r0FCQzQLG/tqb20bRtRfV6BcRa k/RZZlZtzowir8+/HZLw/6lDs3YPwPvpXuSCR3td66AoN3Eletx56QesD zcL+BEssefLysdk9y5zo3Sq8S3almnSFUvGEY3VLvTpxda0/I9OHf8xmk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAI6mOlOtJA2I/2dsb2JhbABZgwaBEsA4gw6BHRZ0giUBAQEDATo9AhACAQgYHgULMiUCBA4gh1YI0VkXjj0zB4MkgRQBA5Rqg2ySOYFxgT+CKw X-IronPort-AV: E=Sophos;i="4.97,772,1389744000"; d="scan'208";a="311247116" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 01 Apr 2014 11:51:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s31Bp5IP031367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 11:51:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 06:51:05 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 3.1 Thread-Index: AQHPTaCojy1+kV1IpES0jYaZfb4npQ== Date: Tue, 1 Apr 2014 11:51:03 +0000 Message-ID: <08D1B3BD-A983-46AF-865E-B630132B91CA@cisco.com> References: <201403311610.s2VGAEV60522@magenta.juniper.net> In-Reply-To: <201403311610.s2VGAEV60522@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.194.105] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A9F35C006DE2847A477FBA9C886D304@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Ye1J1S5hvbPRs_T73BB09hlcaUQ Cc: "" Subject: Re: [spring] New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 3.1 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, 01 Apr 2014 11:51:18 -0000 Hi Yakov, thanks for you comment. See below. On Mar 31, 2014, at 6:10 PM, Yakov Rekhter wrote: >> All, >>=20 >> despite the large consensus draft-previdi-spring-problem-statement-00=20 >> already got on the list, and in order to address the few comments we >> received about the lack of use cases details in the draft, the authors=20 >> decided to include in the problem-statement draft the use-cases original= ly=20 >> described in draft-filsfils-spring-segment-routing-use-cases.=20 >>=20 >> We took the use cases, obviously without any reference to a solution, an= d=20 >> inserted them into the problem statement draft. We will rework the segme= nt >> routing use cases draft in order not to have duplicated text. >=20 > If indeed you "took the use cases, obviously without any reference > to a solution", then what is the following from 3.1, but a solution ? >=20 > Upon receiving a packet from A destined to Z, > PE1 pushes two labels onto the packet: the top label is the Prefix > SID attached to 192.168.0.2/32, the bottom label is the VPN label LZ > attached to the VPN route Z. correct and well spotted. I'll fix it asap. s. >=20 > Yakov. >=20 From nobody Tue Apr 1 05:39: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 726C31A06C9; Tue, 1 Apr 2014 05:39:50 -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 0dPWvHriJySX; Tue, 1 Apr 2014 05:39:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 876A31A06C2; Tue, 1 Apr 2014 05:39:45 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401123945.8694.30547.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 05:39:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/NBAtMODd1FyjAiwi1Y67edU17-M Cc: spring@ietf.org Subject: [spring] I-D Action: draft-francois-spring-resiliency-use-case-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: Tue, 01 Apr 2014 12:39:50 -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 : Use-cases for Resiliency in SPRING Authors : Pierre Francois Clarence Filsfils Bruno Decraene Rob Shakir Filename : draft-francois-spring-resiliency-use-case-01.txt Pages : 6 Date : 2014-04-01 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-francois-spring-resiliency-use-case/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-francois-spring-resiliency-use-case-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-francois-spring-resiliency-use-case-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 Tue Apr 1 05:46: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 8CF651A06C5 for ; Tue, 1 Apr 2014 05:46:05 -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 xH-FAwpl4HML for ; Tue, 1 Apr 2014 05:46:02 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 59BFB1A06BE for ; Tue, 1 Apr 2014 05:46:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 6E2CC1CB7CD for ; Tue, 1 Apr 2014 14:44:43 +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 wYLvCcf6DeVF for ; Tue, 1 Apr 2014 14:44:43 +0200 (CEST) Received: from [10.61.163.76] (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 D0D991CB7CC for ; Tue, 1 Apr 2014 14:44:42 +0200 (CEST) From: Pierre Francois Content-Type: multipart/alternative; boundary="Apple-Mail=_A77F35C0-F5A3-485C-A40A-8C9114B09C6C" Date: Tue, 1 Apr 2014 14:45:55 +0200 References: <20140401123945.8694.30547.idtracker@ietfa.amsl.com> To: "spring@ietf.org" Message-Id: <1E9EB7F0-2A74-40D6-A68D-916F1F5E05D4@imdea.org> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/tCYjvtqmak8fIXg2O-bMnQzqhow Subject: [spring] Fwd: I-D Action: draft-francois-spring-resiliency-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: Tue, 01 Apr 2014 12:46:05 -0000 --Apple-Mail=_A77F35C0-F5A3-485C-A40A-8C9114B09C6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello everyone,=20 We seemed to have some form of consensus on the relevance of the draft, = but we also received multiple comments=20 on the list, mostly asking to remove references to solutions from the = document.=20 Here comes an update to the draft trying to satisfy these comments. Cheers,=20 Pierre. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-francois-spring-resiliency-use-case-01.txt > Date: April 1, 2014 2:39:45 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: spring@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=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-francois-spring-resiliency-use-case-01.txt > Pages : 6 > Date : 2014-04-01 >=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-francois-spring-resiliency-use-case= / >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-francois-spring-resiliency-use-case-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-francois-spring-resiliency-use-ca= se-01 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_A77F35C0-F5A3-485C-A40A-8C9114B09C6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: I-D Action: = draft-francois-spring-resiliency-use-case-01.txt
Date: April 1, 2014 = 2:39:45 PM GMT+02:00
Reply-To: = internet-drafts@ietf.org
<= /span>


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
=             &n= bsp;           &nbs= p;Clarence Filsfils
=             &n= bsp;           &nbs= p;Bruno Decraene
=             &n= bsp;           &nbs= p;Rob Shakir
= Filename        : = draft-francois-spring-resiliency-use-case-01.txt
Pages =           : 6
Date =            : = 2014-04-01

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-francois-spring-resilien= cy-use-case/

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

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-francois-spring-resiliency= -use-case-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/

________________________= _______________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= = --Apple-Mail=_A77F35C0-F5A3-485C-A40A-8C9114B09C6C-- From nobody Tue Apr 1 12:34: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 C08761A06E7 for ; Tue, 1 Apr 2014 12:34:38 -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 br2EyDEtRT2h for ; Tue, 1 Apr 2014 12:34:36 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 52BD91A06BC for ; Tue, 1 Apr 2014 12:34:36 -0700 (PDT) X-AuditID: c6180641-b7ff18e000004bc5-70-533b11e02e4f Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B3.D0.19397.0E11B335; Tue, 1 Apr 2014 21:22:08 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 1 Apr 2014 15:34:31 -0400 From: Gregory Mirsky To: "draft-francois-spring-resiliency-use-case@tools.ietf.org" Thread-Topic: Mail regarding draft-francois-spring-resiliency-use-case Thread-Index: Ac9N3QNGura6Un3pQQOXyEFX3eEwwA== Date: Tue, 1 Apr 2014 19:34:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78CC6F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B78CC6Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXRPlO4DQetgg95PBhbbdj1ksTh+4Tej A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXx/cVL5oJ274q+aZeYGxi/O3YxcnBICJhI dD7z7GLkBDLFJC7cW8/WxcjFISRwlFFi6fn77BDOMkaJc71XGEGq2ASMJF5s7GEHsUUEqiV+ fbjNDGIzC6hLLNt/gQXEFhZwlNi88QETRI2bxKQTrawgy0QE9CTeXtQECbMIqEhsu/qJFcTm FfCVmLywGWwMI9AR30+tYYIYKS5x68l8JojjBCSW7DnPDGGLSrx8/I8VwlaSmLT0HCtEfb7E sY0LmCFmCkqcnPmEZQKj8Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKv YuQoLU4ty003MtzECIyRYxJsjjsYF3yyPMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQbGvJUGJh4592U3KlfVFvFZXdjmLbPkhqJZpo180I45b1IkLh6Q6z7pWzxvOXP0 t5K3Ft31PlJ809Yl19pcnRc4U8/M3GVR/a11K+a83Za6rynETf3I18lffPZHCZZfvqxvZ/M3 wWhydkmB2AaHGwxXt87Wcff4PfuhcMEaGfE6+dVH5ppdDzZVYinOSDTUYi4qTgQAoXDfO18C AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/spring/PhYnBonXb-njvnc-O913-4Olmtw Cc: "spring@ietf.org" Subject: [spring] Mail regarding draft-francois-spring-resiliency-use-case 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, 01 Apr 2014 19:34:39 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78CC6Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, please find my comments and questions to the latest version below. Thank yo= u for your kind consideration. * Would you agree that use case document is more appropriate on Inf= ormational rather than Standard track * Introduction, second para o Precomputation and instantiation of protection/backup paths is characte= ristic of all protection mechanisms, local, segment and end-to-end. o "The term "protection" is often used as a synonym for FRR." I think tha= t it is "local protection" that is being equated and used interchangeably w= ith FRR. End-to-end protection, whether linear or ring, equally supports 10= msec fault detection as fault detection latency is not characteristic of pr= otection mechanism but of interval used in continuity check OAM. * Section 3 o first sentence s/in/of/ o Does local protection in SPRING network domain takes into consideration= SID labels. If SID labels are not being considered when pre-calculating ba= ckup tunnels then it is possible that after the switchover end-to-end path = fails. On the other hand, if SID labels being considered, then, in general = case, intermediate node must maintain path information, which is not as Seg= ment Routing paradigm being defined at this time. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B78CC6Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et. al,

please find my comments and questions to the latest = version below. Thank you for your kind consideration.

·         Would you agree that use case document is mo= re appropriate on Informational rather than Standard track

·         Introduction, second para

o   Precomputation and instantiation of protecti= on/backup paths is characteristic of all protection mechanisms, local, segm= ent and end-to-end.

o   “The term "protection" is of= ten used as a synonym for FRR.” I think that it is “local prote= ction” that is being equated and used interchangeably with FRR. End-t= o-end protection, whether linear or ring, equally supports 10msec fault detection as fault detection latency is not characteristic of protec= tion mechanism but of interval used in continuity check OAM.

·         Section 3

o   first sentence s/in/of/

o   Does local protection in SPRING network doma= in takes into consideration SID labels. If SID labels are not being conside= red when pre-calculating backup tunnels then it is possible that after the = switchover end-to-end path fails. On the other hand, if SID labels being considered, then, in general case, = intermediate node must maintain path information, which is not as Segment R= outing paradigm being defined at this time.

 

Regards,

    &= nbsp;           Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B78CC6Feusaamb103erics_-- From nobody Tue Apr 1 12:59:19 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 C8CAD1A08C8 for ; Tue, 1 Apr 2014 12:59:16 -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 2pQlBAdYrXgE for ; Tue, 1 Apr 2014 12:59:13 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7D51A09E2 for ; Tue, 1 Apr 2014 12:59:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 6307C1CF7DB; Tue, 1 Apr 2014 21:57:51 +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 yaZsCCb2HYSQ; Tue, 1 Apr 2014 21:57:51 +0200 (CEST) Received: from [10.130.181.195] (182.Red-176-83-42.dynamicIP.rima-tde.net [176.83.42.182]) (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 0C8F81CF7DA; Tue, 1 Apr 2014 21:57:50 +0200 (CEST) References: <7347100B5761DC41A166AC17F22DF1121B78CC6F@eusaamb103.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B78CC6F@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary=Apple-Mail-F820EE16-56C9-4DEA-8737-12BF4D6C829A Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B651) From: Pierre Francois Date: Tue, 1 Apr 2014 21:59:04 +0200 To: Gregory Mirsky Archived-At: http://mailarchive.ietf.org/arch/msg/spring/O_kfl11gVrO99XFFeJCyC5UPiuo Cc: "spring@ietf.org" , "draft-francois-spring-resiliency-use-case@tools.ietf.org" Subject: Re: [spring] Mail regarding draft-francois-spring-resiliency-use-case 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, 01 Apr 2014 19:59:16 -0000 --Apple-Mail-F820EE16-56C9-4DEA-8737-12BF4D6C829A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Greg, Answers inline. Sent from my iPhone > On Apr 1, 2014, at 9:34 PM, Gregory Mirsky w= rote: >=20 > Dear Authors, et. al, > please find my comments and questions to the latest version below. Thank y= ou for your kind consideration. > =C2=B7 Would you agree that use case document is more appropriate o= n Informational rather than Standard track Indeed. I'll change it for -02. > =C2=B7 Introduction, second para > o Precomputation and instantiation of protection/backup paths is charact= eristic of all protection mechanisms, local, segment and end-to-end. > o =E2=80=9CThe term "protection" is often used as a synonym for FRR.=E2=80= =9D I think that it is =E2=80=9Clocal protection=E2=80=9D that is being equa= ted and used interchangeably with FRR. End-to-end protection, whether linear= or ring, equally supports 10msec fault detection as fault detection latency= is not characteristic of protection mechanism but of interval used in conti= nuity check OAM Indeed. I'll fix it in next rev. > =C2=B7 Section 3 > o first sentence s/in/of/ Thanks for the catch. > o Does local protection in SPRING network domain takes into consideratio= n SID labels. If SID labels are not being considered when pre-calculating ba= ckup tunnels then it is possible that after the switchover end-to-end path f= ails. On the other hand, if SID labels being considered, then, in general ca= se, intermediate node must maintain path information, which is not as Segmen= t Routing paradigm being defined at this time. > =20 Well now that the draft is not about solutions or specifics of SR, this is n= ot a problem anymore :)=20 More seriously, yes, in SR, you have to pay attention to label allocation wh= en installing your failover entries in the FIB. However I do not see why it l= eads to having intermediate nodes maintain path information.=20 Can you expand on this part of your comment? Cheers, Pierre. > Regards, > Greg > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail-F820EE16-56C9-4DEA-8737-12BF4D6C829A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello Greg,
<= br>
Answers inline.

Sent from my iPhone

On Ap= r 1, 2014, at 9:34 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

=

Dear Authors, et. al,

please find my comments and questions to the latest v= ersion below. Thank you for your kind consideration.

=C2=B7         Would you agree that use case document is= more appropriate on Informational rather than Standard track


Indeed. I'll change it for -02.

=C2=B7         Introduction, second para

o   Precomputation and instantiation of prote= ction/backup paths is characteristic of all protection mechanisms, local, se= gment and end-to-end.

o   =E2=80=9CThe term "protection" is often u= sed as a synonym for FRR.=E2=80=9D I think that it is =E2=80=9Clocal protect= ion=E2=80=9D that is being equated and used interchangeably with FRR. End-to= -end protection, whether linear or ring, equally supports 10msec fault detection as fault detection latency is not characteristic of protect= ion mechanism but of interval used in continuity check OAM


Indeed. I'll fix it in next rev.

=C2=B7         Section 3

o   first sentence s/in/of/


Thanks for the catch.

<= /o:p>

o   Does local protection in SPRING network d= omain takes into consideration SID labels. If SID labels are not being consi= dered when pre-calculating backup tunnels then it is possible that after the= switchover end-to-end path fails. On the other hand, if SID labels being considered, then, in general case, i= ntermediate node must maintain path information, which is not as Segment Rou= ting paradigm being defined at this time.

 

Well now that the draft is not about solutions or specifics of S= R, this is not a problem anymore :) 

More seri= ously, yes, in SR, you have to pay attention to label allocation when instal= ling your failover entries in the FIB. However I do not see why it leads to h= aving intermediate nodes maintain path information. 
Can you e= xpand on this part of your comment?

Cheers,

Pierre.

Regards,

    &n= bsp;           Greg

____________________= ___________________________
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-F820EE16-56C9-4DEA-8737-12BF4D6C829A-- From nobody Wed Apr 2 07:25:22 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 2D9581A022A for ; Wed, 2 Apr 2014 07:25:21 -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 lNrGPP57eQPu for ; Wed, 2 Apr 2014 07:25:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4951A0225 for ; Wed, 2 Apr 2014 07:25:16 -0700 (PDT) Received: from mail223-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 14:25:12 +0000 Received: from mail223-ch1 (localhost [127.0.0.1]) by mail223-ch1-R.bigfish.com (Postfix) with ESMTP id E0983340568; Wed, 2 Apr 2014 14:25:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zf7Iz1432I14ffIzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail223-ch1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail223-ch1 (localhost.localdomain [127.0.0.1]) by mail223-ch1 (MessageSwitch) id 1396448708375782_21455; Wed, 2 Apr 2014 14:25:08 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail223-ch1.bigfish.com (Postfix) with ESMTP id 4D388160055; Wed, 2 Apr 2014 14:25:08 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 14:25:06 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Apr 2014 07:25:05 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s32EOxV75948; Wed, 2 Apr 2014 07:25:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404021425.s32EOxV75948@magenta.juniper.net> To: Pierre Francois In-Reply-To: <1E9EB7F0-2A74-40D6-A68D-916F1F5E05D4@imdea.org> References: <20140401123945.8694.30547.idtracker@ietfa.amsl.com> <1E9EB7F0-2A74-40D6-A68D-916F1F5E05D4@imdea.org> X-MH-In-Reply-To: Pierre Francois message dated "Tue, 01 Apr 2014 14:45:55 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81442.1396448699.1@juniper.net> Date: Wed, 2 Apr 2014 07:24:59 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/kb-ViKh7VdXW897PbEO6kkF6uo8 Cc: "spring@ietf.org" Subject: Re: [spring] Fwd: I-D Action: draft-francois-spring-resiliency-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, 02 Apr 2014 14:25:21 -0000 Pierre, > Hello everyone, > > We seemed to have some form of consensus on the relevance of the draft, > but we also received multiple comments > on the list, mostly asking to remove references to solutions from the > document. > > Here comes an update to the draft trying to satisfy these comments. The update certainly addresses my comments wrt mixing use case and solution. Thanks ! I have few more comments on the update. > 3. Management-free local protection > > An alternative protection strategy consists in management-free local > protection. > > For example, a PW from C to E, transported over the shortest path to > E provided by the SPRING architecture, benefits from management-free > local protection by having each node along the path (e.g. C and D) > automatically pre-compute and pre-install a backup path for the > destination E. Upon local detection of the failure, the traffic is > repaired over the backup path in sub-50msec. > > The backup path computation should support the following > requirements: > > o 100% link, node, and SRLG protection in any topology > o Automated computation by the IGP > o Selection of the backup path such as to minimize the chance for > transient congestion and/or delay during the protection period, as > reflected by the IGP metric configuration in the network. > > > 4. Managed local protection > > There may be cases where a management free repair does not fit the > policy of the operator. For example, the operator may want the > backup path to end at the next-hop (or next-next-hop for node > failure) hence excluding IPFRR/LFA types of backup path. Also, the Such a backup path could be automatically pre-computed and pre-installed, providing the management-free local protection. > operator might want to tightly control the backup path to the next- > hop: for the destination Z upon the failure of link CD, the backup > path CGHD might be desired while the backup paths CGD and CHD are > refused. > > The protection mechanism must support the explicit configuration of > the backup path either under the form of high-level constraints (end > at the next-hop, end at the next-next-hop, minimize this metric, > avoid this SRLG...) or under the form of an explicit path. It seems that the key distinction between 3 and 4 is that 3 relies on LFA (and its variations), while 4 relies on building link/node bypasses. Both LFA-based protection, and protection based on link/node bypasses could be fully automated. It is true however, that with link/node bypasses the operator, if desired, could have a fairly detailed control over the bypass. With this in mind I would suggest to change the title of Section 3 to something like "LFA-based local protection", Section 4 to something like "Local protection based on link/node bypasses", and also change the first sentence in section 4 to something like the following: There may be cases where an LFA-based protection local protection does not fit the policy of the operator. Yakov. From nobody Wed Apr 2 09:28:44 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 10D071A01FB for ; Wed, 2 Apr 2014 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FL0NEicr3Qjn for ; Wed, 2 Apr 2014 09:28:38 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id E218C1A023E for ; Wed, 2 Apr 2014 09:28:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 6AA8A1C16AB; Wed, 2 Apr 2014 18:27:13 +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 62yEvPLVXYrG; Wed, 2 Apr 2014 18:27:13 +0200 (CEST) Received: from [10.61.163.76] (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 649921C16AA; Wed, 2 Apr 2014 18:27:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pierre Francois In-Reply-To: <201404021425.s32EOxV75948@magenta.juniper.net> Date: Wed, 2 Apr 2014 18:28:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140401123945.8694.30547.idtracker@ietfa.amsl.com> <1E9EB7F0-2A74-40D6-A68D-916F1F5E05D4@imdea.org> <201404021425.s32EOxV75948@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/5c3kmFetTDAHx6DXRFgnAXphdzI Cc: "spring@ietf.org" Subject: Re: [spring] Fwd: I-D Action: draft-francois-spring-resiliency-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, 02 Apr 2014 16:28:43 -0000 Hello Yakov,=20 On Apr 2, 2014, at 4:24 PM, Yakov Rekhter wrote: > Pierre, >=20 >> Hello everyone, >>=20 >> We seemed to have some form of consensus on the relevance of the = draft,=20 >> but we also received multiple comments >> on the list, mostly asking to remove references to solutions from the=20= >> document. >>=20 >> Here comes an update to the draft trying to satisfy these comments. >=20 > The update certainly addresses my comments wrt mixing use case > and solution. Thanks ! >=20 > I have few more comments on the update. >=20 >> 3. Management-free local protection >>=20 >> An alternative protection strategy consists in management-free = local >> protection. >>=20 >> For example, a PW from C to E, transported over the shortest path = to >> E provided by the SPRING architecture, benefits from = management-free >> local protection by having each node along the path (e.g. C and D) >> automatically pre-compute and pre-install a backup path for the >> destination E. Upon local detection of the failure, the traffic is >> repaired over the backup path in sub-50msec. >>=20 >> The backup path computation should support the following >> requirements: >>=20 >> o 100% link, node, and SRLG protection in any topology >> o Automated computation by the IGP >> o Selection of the backup path such as to minimize the chance for >> transient congestion and/or delay during the protection period, = as >> reflected by the IGP metric configuration in the network. >>=20 >>=20 >> 4. Managed local protection >>=20 >> There may be cases where a management free repair does not fit the >> policy of the operator. For example, the operator may want the >> backup path to end at the next-hop (or next-next-hop for node >> failure) hence excluding IPFRR/LFA types of backup path. Also, the >=20 > Such a backup path could be automatically pre-computed and = pre-installed, > providing the management-free local protection. Indeed. I'm getting the feeling that the next-hop/next-next-hop example = of section 4 is not well=20 chosen for what we were trying to achieve :) The use case of section 4 is basically: Give freedom to the operator on = the definition of the repair path.=20 We say that SPRING should allow the operator to define the protection he = wants with the=20 precision that he needs. More on this below, as it's related with your = other comments.=20 >=20 >=20 >> operator might want to tightly control the backup path to the next- >> hop: for the destination Z upon the failure of link CD, the backup >> path CGHD might be desired while the backup paths CGD and CHD are >> refused. >>=20 >> The protection mechanism must support the explicit configuration of >> the backup path either under the form of high-level constraints = (end >> at the next-hop, end at the next-next-hop, minimize this metric, >> avoid this SRLG...) or under the form of an explicit path.=20 >=20 > It seems that the key distinction between 3 and 4 is that 3 relies > on LFA (and its variations), while 4 relies on building link/node > bypasses. Mmm, it was more: section 3 relies on automated protection established = by the router, as experience showed that it most often does the job, while section 4 relies on operator = input to the router, in order to achieve a protection path that better = fits his policy. > Both LFA-based protection, and protection based on > link/node bypasses could be fully automated. It is true however, > that with link/node bypasses the operator, if desired, could have > a fairly detailed control over the bypass. Similarly to the link/node bypass approach, there are ways to provide = more detailed control=20 in some IP-FRR variants. =20 >=20 > With this in mind I would suggest to change the title of Section 3 > to something like "LFA-based local protection", Section 4 > to something like "Local protection based on link/node bypasses", > and also change the first sentence in section 4 to something like > the following: >=20 > There may be cases where an LFA-based protection local protection > does not fit the policy of the operator. Based on your comments and mine, I would suggest the following ToC, as I = think it=20 unifies our views on the topic: 1. Path protection 2. Unmanaged local protection 2.1 Shortest path based / IP-FRR variants=20 2.2 Automated link/node bypass (as per your comment that link/node bypasses provide an unmanaged = solutions) 3. Managed local protection 3.1 managed shortest path based protection (allowing for constraints on the repair brought by the IP-FRR machinery, = with the level of granularity as currently described in the doc. ) 3.2 managed link/node bypass based protection (allowing for the detailed control over the bypass, as you mentioned) Does that make sense to you? Thanks a lot for your feedback,=20 Pierre. >=20 > Yakov. >=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Apr 2 09:45: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 2FF381A0254 for ; Wed, 2 Apr 2014 09:45:26 -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 kIjLgIm_AtAY for ; Wed, 2 Apr 2014 09:45:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id C4AF01A02A7 for ; Wed, 2 Apr 2014 09:45:21 -0700 (PDT) Received: from mail137-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 16:45:17 +0000 Received: from mail137-ch1 (localhost [127.0.0.1]) by mail137-ch1-R.bigfish.com (Postfix) with ESMTP id 6A1E54A046A; Wed, 2 Apr 2014 16:45:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zf7Iz98dI9371I1432I14ffIzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1de097hz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail137-ch1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail137-ch1 (localhost.localdomain [127.0.0.1]) by mail137-ch1 (MessageSwitch) id 1396457114930031_18059; Wed, 2 Apr 2014 16:45:14 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail137-ch1.bigfish.com (Postfix) with ESMTP id D37023C00CD; Wed, 2 Apr 2014 16:45:14 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 16:45:14 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Apr 2014 09:45:13 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s32Gj0V75754; Wed, 2 Apr 2014 09:45:05 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404021645.s32Gj0V75754@magenta.juniper.net> To: Pierre Francois In-Reply-To: References: <20140401123945.8694.30547.idtracker@ietfa.amsl.com> <1E9EB7F0-2A74-40D6-A68D-916F1F5E05D4@imdea.org> <201404021425.s32EOxV75948@magenta.juniper.net> X-MH-In-Reply-To: Pierre Francois message dated "Wed, 02 Apr 2014 18:28:27 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84402.1396457097.1@juniper.net> Date: Wed, 2 Apr 2014 09:44:57 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/_ppbI9mpolM8USpafWRfZ2VaR8I Cc: "spring@ietf.org" Subject: Re: [spring] Fwd: I-D Action: draft-francois-spring-resiliency-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, 02 Apr 2014 16:45:26 -0000 Pierre, > Hello Yakov, > > On Apr 2, 2014, at 4:24 PM, Yakov Rekhter wrote: > > > Pierre, > > > >> Hello everyone, > >> > >> We seemed to have some form of consensus on the relevance of the draft, > >> but we also received multiple comments > >> on the list, mostly asking to remove references to solutions from the > >> document. > >> > >> Here comes an update to the draft trying to satisfy these comments. > > > > The update certainly addresses my comments wrt mixing use case > > and solution. Thanks ! > > > > I have few more comments on the update. > > > >> 3. Management-free local protection > >> > >> An alternative protection strategy consists in management-free local > >> protection. > >> > >> For example, a PW from C to E, transported over the shortest path to > >> E provided by the SPRING architecture, benefits from management-free > >> local protection by having each node along the path (e.g. C and D) > >> automatically pre-compute and pre-install a backup path for the > >> destination E. Upon local detection of the failure, the traffic is > >> repaired over the backup path in sub-50msec. > >> > >> The backup path computation should support the following > >> requirements: > >> > >> o 100% link, node, and SRLG protection in any topology > >> o Automated computation by the IGP > >> o Selection of the backup path such as to minimize the chance for > >> transient congestion and/or delay during the protection period, as > >> reflected by the IGP metric configuration in the network. > >> > >> > >> 4. Managed local protection > >> > >> There may be cases where a management free repair does not fit the > >> policy of the operator. For example, the operator may want the > >> backup path to end at the next-hop (or next-next-hop for node > >> failure) hence excluding IPFRR/LFA types of backup path. Also, the > > > > Such a backup path could be automatically pre-computed and pre-installed, > > providing the management-free local protection. > > Indeed. I'm getting the feeling that the next-hop/next-next-hop > example of section 4 is not well > chosen for what we were trying to achieve :) Correct :-) > The use case of section 4 is basically: Give freedom to the operator on > the definition of the repair path. > We say that SPRING should allow the operator to define the protection > he wants with the > precision that he needs. More on this below, as it's related with > your other comments. > > > > > > >> operator might want to tightly control the backup path to the next- > >> hop: for the destination Z upon the failure of link CD, the backup > >> path CGHD might be desired while the backup paths CGD and CHD are > >> refused. > >> > >> The protection mechanism must support the explicit configuration of > >> the backup path either under the form of high-level constraints (end > >> at the next-hop, end at the next-next-hop, minimize this metric, > >> avoid this SRLG...) or under the form of an explicit path. > > > > It seems that the key distinction between 3 and 4 is that 3 relies > > on LFA (and its variations), while 4 relies on building link/node > > bypasses. > > Mmm, it was more: section 3 relies on automated protection established by > the router, as experience showed > that it most often does the job, while section 4 relies on operator input > to the router, in order to achieve a protection path that better fits > his policy. > > > Both LFA-based protection, and protection based on > > link/node bypasses could be fully automated. It is true however, > > that with link/node bypasses the operator, if desired, could have > > a fairly detailed control over the bypass. > > Similarly to the link/node bypass approach, there are ways to provide > more detailed control in some IP-FRR variants. > > > With this in mind I would suggest to change the title of Section 3 > > to something like "LFA-based local protection", Section 4 > > to something like "Local protection based on link/node bypasses", > > and also change the first sentence in section 4 to something like > > the following: > > > > There may be cases where an LFA-based protection local protection > > does not fit the policy of the operator. > > > Based on your comments and mine, I would suggest the following ToC, as > I think it unifies our views on the topic: > > 1. Path protection > > 2. Unmanaged local protection > > 2.1 Shortest path based / IP-FRR variants > 2.2 Automated link/node bypass > (as per your comment that link/node bypasses provide an unmanaged solutions) > > 3. Managed local protection > > 3.1 managed shortest path based protection > (allowing for constraints on the repair brought by the IP-FRR machinery, > with the level of granularity as currently described in the doc. ) > > 3.2 managed link/node bypass based protection > (allowing for the detailed control over the bypass, as you mentioned) > > Does that make sense to you? Yes, it does make sense. The ToC you proposed above is fine. Yakov. From nobody Wed Apr 2 09:53: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 78A391A02DE for ; Wed, 2 Apr 2014 09:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0vP13tGn0Jjq for ; Wed, 2 Apr 2014 09:53:49 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id D17281A0232 for ; Wed, 2 Apr 2014 09:53:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id AAE611CF7EF; Wed, 2 Apr 2014 18:52:28 +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 CZ82FkU49Ujh; Wed, 2 Apr 2014 18:52:28 +0200 (CEST) Received: from [10.61.163.76] (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 DB3A51CF7EE; Wed, 2 Apr 2014 18:52:27 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pierre Francois In-Reply-To: <201404021645.s32Gj0V75754@magenta.juniper.net> Date: Wed, 2 Apr 2014 18:53:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A8E000B-16DA-41DD-A13D-88773B65A2C9@imdea.org> References: <20140401123945.8694.30547.idtracker@ietfa.amsl.com> <1E9EB7F0-2A74-40D6-A68D-916F1F5E05D4@imdea.org> <201404021425.s32EOxV75948@magenta.juniper.net> <201404021645.s32Gj0V75754@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/kZBRWBPI0YczjCMo3H8mRvmeG1U Cc: "spring@ietf.org" Subject: Re: [spring] Fwd: I-D Action: draft-francois-spring-resiliency-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, 02 Apr 2014 16:53:53 -0000 Yakov,=20 Okay I'll stick to the proposed ToC for rev -02.=20 ( and put a better example in former section 4 ;) ) Cheers,=20 Pierre. On Apr 2, 2014, at 6:44 PM, Yakov Rekhter wrote: > Pierre, >=20 >> Hello Yakov,=20 >>=20 >> On Apr 2, 2014, at 4:24 PM, Yakov Rekhter wrote: >>=20 >>> Pierre, >>>=20 >>>> Hello everyone, >>>>=20 >>>> We seemed to have some form of consensus on the relevance of the = draft,=20 >>>> but we also received multiple comments >>>> on the list, mostly asking to remove references to solutions from = the=20 >>>> document. >>>>=20 >>>> Here comes an update to the draft trying to satisfy these comments. >>>=20 >>> The update certainly addresses my comments wrt mixing use case >>> and solution. Thanks ! >>>=20 >>> I have few more comments on the update. >>>=20 >>>> 3. Management-free local protection >>>>=20 >>>> An alternative protection strategy consists in management-free = local >>>> protection. >>>>=20 >>>> For example, a PW from C to E, transported over the shortest path = to >>>> E provided by the SPRING architecture, benefits from = management-free >>>> local protection by having each node along the path (e.g. C and = D) >>>> automatically pre-compute and pre-install a backup path for the >>>> destination E. Upon local detection of the failure, the traffic is >>>> repaired over the backup path in sub-50msec. >>>>=20 >>>> The backup path computation should support the following >>>> requirements: >>>>=20 >>>> o 100% link, node, and SRLG protection in any topology >>>> o Automated computation by the IGP >>>> o Selection of the backup path such as to minimize the chance for >>>> transient congestion and/or delay during the protection period, = as >>>> reflected by the IGP metric configuration in the network. >>>>=20 >>>>=20 >>>> 4. Managed local protection >>>>=20 >>>> There may be cases where a management free repair does not fit the >>>> policy of the operator. For example, the operator may want the >>>> backup path to end at the next-hop (or next-next-hop for node >>>> failure) hence excluding IPFRR/LFA types of backup path. Also, = the >>>=20 >>> Such a backup path could be automatically pre-computed and = pre-installed, >>> providing the management-free local protection. >>=20 >> Indeed. I'm getting the feeling that the next-hop/next-next-hop=20 >> example of section 4 is not well=20 >> chosen for what we were trying to achieve :) >=20 > Correct :-) >=20 >> The use case of section 4 is basically: Give freedom to the operator = on=20 >> the definition of the repair path.=20 >> We say that SPRING should allow the operator to define the protection=20= >> he wants with the=20 >> precision that he needs. More on this below, as it's related with=20 >> your other comments.=20 >>=20 >>>=20 >>>=20 >>>> operator might want to tightly control the backup path to the = next- >>>> hop: for the destination Z upon the failure of link CD, the backup >>>> path CGHD might be desired while the backup paths CGD and CHD are >>>> refused. >>>>=20 >>>> The protection mechanism must support the explicit configuration = of >>>> the backup path either under the form of high-level constraints = (end >>>> at the next-hop, end at the next-next-hop, minimize this metric, >>>> avoid this SRLG...) or under the form of an explicit path.=20 >>>=20 >>> It seems that the key distinction between 3 and 4 is that 3 relies >>> on LFA (and its variations), while 4 relies on building link/node >>> bypasses. >>=20 >> Mmm, it was more: section 3 relies on automated protection = established by=20 >> the router, as experience showed >> that it most often does the job, while section 4 relies on operator = input=20 >> to the router, in order to achieve a protection path that better fits=20= >> his policy. >>=20 >>> Both LFA-based protection, and protection based on >>> link/node bypasses could be fully automated. It is true however, >>> that with link/node bypasses the operator, if desired, could have >>> a fairly detailed control over the bypass. >>=20 >> Similarly to the link/node bypass approach, there are ways to provide=20= >> more detailed control in some IP-FRR variants. =20 >>=20 >>> With this in mind I would suggest to change the title of Section 3 >>> to something like "LFA-based local protection", Section 4 >>> to something like "Local protection based on link/node bypasses", >>> and also change the first sentence in section 4 to something like >>> the following: >>>=20 >>> There may be cases where an LFA-based protection local protection >>> does not fit the policy of the operator. >>=20 >>=20 >> Based on your comments and mine, I would suggest the following ToC, = as=20 >> I think it unifies our views on the topic: >>=20 >> 1. Path protection >>=20 >> 2. Unmanaged local protection >>=20 >> 2.1 Shortest path based / IP-FRR variants=20 >> 2.2 Automated link/node bypass >> (as per your comment that link/node bypasses provide an unmanaged = solutions) >>=20 >> 3. Managed local protection >>=20 >> 3.1 managed shortest path based protection >> (allowing for constraints on the repair brought by the IP-FRR = machinery,=20 >> with the level of granularity as currently described in the doc. ) >>=20 >> 3.2 managed link/node bypass based protection >> (allowing for the detailed control over the bypass, as you mentioned) >>=20 >> Does that make sense to you? >=20 > Yes, it does make sense. The ToC you proposed above is fine. >=20 > Yakov. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Apr 2 10:19:52 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 4C9E41A0295 for ; Wed, 2 Apr 2014 10:19:51 -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 58b8IiXQXlsK for ; Wed, 2 Apr 2014 10:19:46 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 62B001A0231 for ; Wed, 2 Apr 2014 10:17:59 -0700 (PDT) Received: from mail84-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE018.bigfish.com (10.3.207.140) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 17:17:54 +0000 Received: from mail84-am1 (localhost [127.0.0.1]) by mail84-am1-R.bigfish.com (Postfix) with ESMTP id 7EFFD1E07BF; Wed, 2 Apr 2014 17:17:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zf7Izda00hdc73hzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail84-am1: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail84-am1 (localhost.localdomain [127.0.0.1]) by mail84-am1 (MessageSwitch) id 1396459073340324_9876; Wed, 2 Apr 2014 17:17:53 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.230]) by mail84-am1.bigfish.com (Postfix) with ESMTP id 4668EE0064; Wed, 2 Apr 2014 17:17:53 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 17:17:53 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Apr 2014 10:17:51 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s32HHnV97776; Wed, 2 Apr 2014 10:17:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404021717.s32HHnV97776@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <85750.1396459069.1@juniper.net> Date: Wed, 2 Apr 2014 10:17:49 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/zL4TY462lefKUbjki12rYu27f-s Cc: spring@ietf.org Subject: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 4 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, 02 Apr 2014 17:19:51 -0000 Stefano, Section 4 ("Fast Reroute") should be removed, as use cases for FRR are covered in draft-francois-spring-resiliency-use-case. Yakov. From nobody Wed Apr 2 10:28: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 2E13F1A02D2 for ; Wed, 2 Apr 2014 10:28:55 -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 zfPAlnuJPdv5 for ; Wed, 2 Apr 2014 10:28:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 46C931A024D for ; Wed, 2 Apr 2014 10:28:50 -0700 (PDT) Received: from mail80-va3-R.bigfish.com (10.7.14.233) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 Apr 2014 17:28:45 +0000 Received: from mail80-va3 (localhost [127.0.0.1]) by mail80-va3-R.bigfish.com (Postfix) with ESMTP id 8171E600F2; Wed, 2 Apr 2014 17:28:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zf7Izzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail80-va3: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail80-va3 (localhost.localdomain [127.0.0.1]) by mail80-va3 (MessageSwitch) id 1396459723895882_10991; Wed, 2 Apr 2014 17:28:43 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.239]) by mail80-va3.bigfish.com (Postfix) with ESMTP id D300F2C008E; Wed, 2 Apr 2014 17:28:43 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 17:28:43 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Apr 2014 10:28:42 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s32HSfV06087; Wed, 2 Apr 2014 10:28:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404021728.s32HSfV06087@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86172.1396459721.1@juniper.net> Date: Wed, 2 Apr 2014 10:28:41 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/9DGWLcNtSrRdeZ0AJxnNTrQYVrc Cc: spring@ietf.org Subject: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - use cases vs requirements 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, 02 Apr 2014 17:28:55 -0000 Stefano, The charter asks for "One or more documents describing SPRING use cases", yet draft-previdi-spring-problem-statement-01 covers not just use cases but the requirements as well. E.g., from section 5: The SPRING architecture should support traffic engineering, including: o loose or strict options o bandwidth admission control o distributed vs. centralized model (PCE, SDN Controller) o disjointness in dual-plane networks o egress peering traffic engineering o load-balancing among non-parallel links o Limiting (scalable, preferably zero) per-service state and signaling on midpoint and tail-end routers. o ECMP-awareness o node resiliency property (i.e.: the traffic-engineering policy is not anchored to a specific core node whose failure could impact the service. E.g., from section 5.1.1.1: The SPRING architecture should support this use case with the following requirements: o Zero per-service state and signaling on midpoint and tail-end routers. o ECMP-awareness. o Node resiliency property: the traffic-engineering policy is not anchored to a specific core node whose failure could impact the service. etc... With all this in mind the authors should keep the scope of the document to use cases, and remove all the text that talks about requirements on SPRING. Yakov. From nobody Wed Apr 2 10:33: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 E17411A0242 for ; Wed, 2 Apr 2014 10:33:00 -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 kKRAzlfDwk4W for ; Wed, 2 Apr 2014 10:32:57 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0AD1A02ED for ; Wed, 2 Apr 2014 10:32:37 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id uy17so634142igb.9 for ; Wed, 02 Apr 2014 10:32:33 -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=en3UfI9P9WX767CZbarNPnBubuu/cr+1Rhm3BAV3IUM=; b=X5RuvtQX8vgAijglbhGGNfz/MUqqh1aJT4acqJmga0MT2p6SOkSlYCf3uAAksXJLa4 4LR++/KNCB1FqV5ba+o4hHBoNJiRPeuItyC2jLa1ExIr+hCnj8KvF2Kq4tnQNVMhzJ7C gpmUnRMypPTlui4i98mxAjF/Q6vYS+uCexb0XsyRlTyC1oln/eGz800rgVzedcxD2RAZ O1tPYydP/UGlP+sBzKngarNZzztbTORfxRYJO4rmY1Pn0lgvabUaSlB++1MYARiyKA1w +G3nT8kYr66mLeaKBeDTzsurwFxszOGz3OCoJDu42MS/PJ3Wmg+pP07kP+eTb4UZofGd Dc8g== MIME-Version: 1.0 X-Received: by 10.42.207.73 with SMTP id fx9mr1588618icb.97.1396459952948; Wed, 02 Apr 2014 10:32:32 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 2 Apr 2014 10:32:32 -0700 (PDT) In-Reply-To: <201404021717.s32HHnV97776@magenta.juniper.net> References: <201404021717.s32HHnV97776@magenta.juniper.net> Date: Wed, 2 Apr 2014 19:32:32 +0200 X-Google-Sender-Auth: zrdUVu2D9c83t_pAy_Qo2t3TkGM Message-ID: From: Robert Raszuk To: Yakov Rekhter Content-Type: multipart/alternative; boundary=20cf303f625a704cd604f612abf5 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/9C9SCDwbO_NsaTG5v3etpGUQ23M Cc: "spring@ietf.org" , stefano previdi Subject: Re: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 4 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, 02 Apr 2014 17:33:01 -0000 --20cf303f625a704cd604f612abf5 Content-Type: text/plain; charset=ISO-8859-1 Hi Yakov, > Section 4 ("Fast Reroute") should be removed, What's wrong in including all possible problems in problem statement document and treating it as a reading roadmap document to more specific drafts describing each problem in more details ? I think such approach may be helpful for the readers. Thx, R. On Wed, Apr 2, 2014 at 7:17 PM, Yakov Rekhter wrote: > Stefano, > > Section 4 ("Fast Reroute") should be removed, as use cases for FRR are > covered in draft-francois-spring-resiliency-use-case. > > Yakov. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --20cf303f625a704cd604f612abf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yakov,

> Se= ction 4 ("Fast Reroute") should be removed,

What's wrong in including all possible problems in problem statement do= cument and treating it as a reading roadmap document to more specific draft= s describing each problem in more details ?=A0

I think such approach may be helpful for = the readers.=A0

Thx,
R.



=
On Wed, Apr 2, 2014 at 7:17 PM, Yakov Rekhte= r <yakov@juniper.net> wrote:
Stefano,

Section 4 ("Fast Reroute") should be removed, as use cases for FR= R are
covered in draft-francois-spring-resiliency-use-case.

Yakov.

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

--20cf303f625a704cd604f612abf5-- From nobody Wed Apr 2 10:40: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 D218D1A0370 for ; Wed, 2 Apr 2014 10:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Tmc-UbmrxnWi for ; Wed, 2 Apr 2014 10:40:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B16CC1A0379 for ; Wed, 2 Apr 2014 10:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1732; q=dns/txt; s=iport; t=1396460395; x=1397669995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xF9ajHvsn8EgXX72PyNWkvrdF57wW2ud99cCdjUSd2Y=; b=A/GGVvfESsHOfrzUYZTDG2MMpkCHkD7If0pU3fpWQjEVLVd4ahvIDmsc O5OBOuXk721//CVhwjmyFolyjn89hVbNG9SoAKaKPVdsQL+IdiiLOmKpL O269LTWxoKH5P7/cQt8+iV14x4YI/6xVUcgfvBIy9VgpBKlDMp1C/Hb0x g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAMVKPFOtJV2a/2dsb2JhbABZgwaBEsNngR8WdIIlAQEBAwE6OgMCEAIBCBIGHgULMhcOAgQOh3YIzzsXjnAHgySBFAEDmFaSOYFxgT+CKw X-IronPort-AV: E=Sophos;i="4.97,781,1389744000"; d="scan'208";a="314667899" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 02 Apr 2014 17:39:54 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s32HdsDG005277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 17:39:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 12:39:54 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - use cases vs requirements Thread-Index: AQHPTpkJfgNM1gdYykWC8jtpt739k5r+67mA Date: Wed, 2 Apr 2014 17:39:53 +0000 Message-ID: <41C955D7-B588-4E44-B06E-69029993FDE5@cisco.com> References: <201404021728.s32HSfV06087@magenta.juniper.net> In-Reply-To: <201404021728.s32HSfV06087@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.212.75] 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/yBvtKBqnac97wXAloDczrNo6KBI Cc: " ietf.org" Subject: Re: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - use cases vs requirements 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, 02 Apr 2014 17:40:18 -0000 Hi Yakov, On Apr 2, 2014, at 7:28 PM, Yakov Rekhter wrote: > Stefano, >=20 > The charter asks for "One or more documents describing SPRING use cases", > yet draft-previdi-spring-problem-statement-01 covers not just > use cases but the requirements as well.=20 well, yes and I don't think it's a bad idea at this stage. s. >=20 > E.g., from section 5: >=20 > The SPRING architecture should support traffic engineering, > including: >=20 > o loose or strict options >=20 > o bandwidth admission control >=20 > o distributed vs. centralized model (PCE, SDN Controller) >=20 > o disjointness in dual-plane networks >=20 > o egress peering traffic engineering >=20 > o load-balancing among non-parallel links >=20 > o Limiting (scalable, preferably zero) per-service state and > signaling on midpoint and tail-end routers. >=20 > o ECMP-awareness >=20 > o node resiliency property (i.e.: the traffic-engineering policy is > not anchored to a specific core node whose failure could impact > the service. >=20 > E.g., from section 5.1.1.1: >=20 > The SPRING architecture should support this use case with the > following requirements: >=20 > o Zero per-service state and signaling on midpoint and tail-end > routers. >=20 > o ECMP-awareness. >=20 > o Node resiliency property: the traffic-engineering policy is not > anchored to a specific core node whose failure could impact the > service. >=20 > etc... >=20 > With all this in mind the authors should keep the scope of the > document to use cases, and remove all the text that talks about > requirements on SPRING. >=20 > Yakov. >=20 >=20 >=20 From nobody Wed Apr 2 10:40:45 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 E22DA1A037E for ; Wed, 2 Apr 2014 10:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 KIMZbHYyOBzp for ; Wed, 2 Apr 2014 10:40:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3916A1A036C for ; Wed, 2 Apr 2014 10:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=361; q=dns/txt; s=iport; t=1396460434; x=1397670034; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RSbhDnh67Gb4dIUEqnlfuxu3bXryz8vqwdGr64tbGnU=; b=ld1nCSe5/reb2hCIdr91bAbBld2QifF/67oEw2cc+SCVMGTZateNEOOZ La5A75fKZzZoC2CCgqMo+/0j/Fya1zv6rYLLMmnSb28qST0jvZv5g7XbR g/ynk1ouWi/MX0EJcq2g7saxlNrIMt1Q7pyf34Vq2wFBg+nrCXIVx/rpy M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAMVKPFOtJA2L/2dsb2JhbABZgwaBEsNngR8WdIIlAQEBAwE6PQIQAgEIGB4FCzIlAgQOh3YIzzsXjnAHgySBFAEDmFaSOYFxgT+CKw X-IronPort-AV: E=Sophos;i="4.97,781,1389744000"; d="scan'208";a="314652536" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 02 Apr 2014 17:40:34 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s32HeYBL003895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 17:40:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 12:40:33 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 4 Thread-Index: AQHPTpd+jQIpzBSBH0mJqaKM9wzPGpr+6+6A Date: Wed, 2 Apr 2014 17:40:33 +0000 Message-ID: References: <201404021717.s32HHnV97776@magenta.juniper.net> In-Reply-To: <201404021717.s32HHnV97776@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.212.75] Content-Type: text/plain; charset="us-ascii" Content-ID: <60A2EF4C5E71944BBE3B2862EF3B1EFA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/WBKHBKTo0_jPrl1vkbVnSsZV1xc Cc: "" Subject: Re: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 4 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, 02 Apr 2014 17:40:44 -0000 Hi Yakov, On Apr 2, 2014, at 7:17 PM, Yakov Rekhter wrote: > Stefano, >=20 > Section 4 ("Fast Reroute") should be removed, as use cases for FRR are > covered in draft-francois-spring-resiliency-use-case. in fact the FRR section of the problem-statement draft points=20 to draft-francois-spring-resiliency-use-case. s. >=20 > Yakov. >=20 From nobody Wed Apr 2 10:46: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 53CCF1A0392 for ; Wed, 2 Apr 2014 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 gSuDN6LY-KT9 for ; Wed, 2 Apr 2014 10:46:44 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 170221A0391 for ; Wed, 2 Apr 2014 10:46:43 -0700 (PDT) Received: from mail200-tx2-R.bigfish.com (10.9.14.232) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 17:46:39 +0000 Received: from mail200-tx2 (localhost [127.0.0.1]) by mail200-tx2-R.bigfish.com (Postfix) with ESMTP id C43CAC05B0; Wed, 2 Apr 2014 17:46:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zf7Izzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail200-tx2: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail200-tx2 (localhost.localdomain [127.0.0.1]) by mail200-tx2 (MessageSwitch) id 1396460797741744_29060; Wed, 2 Apr 2014 17:46:37 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.252]) by mail200-tx2.bigfish.com (Postfix) with ESMTP id A71FA28009C; Wed, 2 Apr 2014 17:46:37 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 17:46:34 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Apr 2014 10:46:33 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s32HkOV18020; Wed, 2 Apr 2014 10:46:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404021746.s32HkOV18020@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86882.1396460783.1@juniper.net> Date: Wed, 2 Apr 2014 10:46:23 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Is2F26lLPy7ZT4IPU3wIR8S3qFc Cc: spring@ietf.org Subject: [spring] Fwd: New Version Notification for draft-previdi-spring-proble m-statement-01.txt - section 5.1.2 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, 02 Apr 2014 17:46:49 -0000 Stefano, Section 5.1.2 contains plenty of material that is not use cases. E.g., section 5.1.2.1 describes capacity planning process, but not a particular use case. Such description is outside the scope of the use case document. E.g., section 5.1.2.2.1 goes into comparison between the scheme where traffic engineering is done by distributed CSPF and the scheme where it is done by using centralized computation for dynamically setting/adjusting IGP metrics based on the traffic load and for computing paths for explicitly routed tunnels. Such comparison is outside the scope of the use case document. Yakov. From nobody Wed Apr 2 10:48:42 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 B68B21A03A2 for ; Wed, 2 Apr 2014 10:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ghJK4KWCt2bc for ; Wed, 2 Apr 2014 10:48:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe007.messaging.microsoft.com [65.55.88.31]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6B1A0394 for ; Wed, 2 Apr 2014 10:48:35 -0700 (PDT) Received: from mail220-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 17:48:31 +0000 Received: from mail220-tx2 (localhost [127.0.0.1]) by mail220-tx2-R.bigfish.com (Postfix) with ESMTP id 6E4829403ED; Wed, 2 Apr 2014 17:48:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zf7Iz98dI9371I1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL8275dh1de097h186068hz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail220-tx2: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail220-tx2 (localhost.localdomain [127.0.0.1]) by mail220-tx2 (MessageSwitch) id 1396460909919698_29817; Wed, 2 Apr 2014 17:48:29 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.236]) by mail220-tx2.bigfish.com (Postfix) with ESMTP id DCEB04C011A; Wed, 2 Apr 2014 17:48:29 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 17:48:29 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Apr 2014 10:48:28 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s32HmRV18926; Wed, 2 Apr 2014 10:48:27 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404021748.s32HmRV18926@magenta.juniper.net> To: "Stefano Previdi (sprevidi)" In-Reply-To: References: <201404021717.s32HHnV97776@magenta.juniper.net> X-MH-In-Reply-To: "Stefano Previdi (sprevidi)" message dated "Wed, 02 Apr 2014 17:40:33 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86967.1396460907.1@juniper.net> Date: Wed, 2 Apr 2014 10:48:27 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/fs7qbjM0vz8UGFodYp8ROntEEQE Cc: "" Subject: Re: [spring] Fwd: New Version Notification for draft-previdi-spring-problem-statement-01.txt - section 4 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, 02 Apr 2014 17:48:41 -0000 Stefano, > Hi Yakov, > > On Apr 2, 2014, at 7:17 PM, Yakov Rekhter wrote: > > Stefano, > > > > Section 4 ("Fast Reroute") should be removed, as use cases for FRR are > > covered in draft-francois-spring-resiliency-use-case. > > > in fact the FRR section of the problem-statement draft points > to draft-francois-spring-resiliency-use-case. And if you insist on keeping this section, then perhaps this pointer is all what this section should contain, as the rest of this section does not describe any use case. Yakov. > > s. > > > > > > Yakov. > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > From nobody Thu Apr 3 00:46:35 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 519C11A010A for ; Thu, 3 Apr 2014 00:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 fUzfmYwJ_6vb for ; Thu, 3 Apr 2014 00:46:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1762E1A00B2 for ; Thu, 3 Apr 2014 00:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=964; q=dns/txt; s=iport; t=1396511185; x=1397720785; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IpL0CS4P02061r03F/TYwHQZFzSfkt8szRcPm/g1M8k=; b=hriNZyvWs5uVYz8QnQOwIsXDI0DL1NU89t4ItLVhvg60uURH+3l0ZNHQ vwAYqwl3SDqfScqpcaxXSQk/NWyUL0pg77uXdTxohKN++03v5jlumwXzH rogkZPw6Dbo0iSLuZM3vh4RE4wkaq1JXzyqbuWDKvH+sbdwSeL5w3Xsb9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEURPVOtJA2N/2dsb2JhbABZgwaBEsNygRsWdIIlAQEBBDo9AhACAQgYHgULMiUCBA4gh17PbBeOcQeDJIEUAQOYWZI+gXGBP4Ir X-IronPort-AV: E=Sophos;i="4.97,785,1389744000"; d="scan'208";a="314875387" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2014 07:46:25 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s337kOjc024898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Apr 2014 07:46:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 02:46:24 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] Fwd: New Version Notification for draft-previdi-spring-proble m-statement-01.txt - section 5.1.2 Thread-Index: AQHPTpuAWTYJGntg6k+50K9fPg3kzpr/2DaA Date: Thu, 3 Apr 2014 07:46:24 +0000 Message-ID: <98C691DB-13D1-49DD-9B1D-957F1693310C@cisco.com> References: <201404021746.s32HkOV18020@magenta.juniper.net> In-Reply-To: <201404021746.s32HkOV18020@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.212.75] 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/22tx8I_D-HSva1iFezk05DCZfM4 Cc: "" Subject: Re: [spring] Fwd: New Version Notification for draft-previdi-spring-proble m-statement-01.txt - section 5.1.2 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, 03 Apr 2014 07:46:33 -0000 Hi Yakov, indeed. It's part of a problem statement that describes how=20 networks are deployed today and how these network may benefit from a SR solution. So, to me, it looks the right place for this description to be. s. On Apr 2, 2014, at 7:46 PM, Yakov Rekhter wrote: > Stefano, >=20 > Section 5.1.2 contains plenty of material that is not use cases. >=20 > E.g., section 5.1.2.1 describes capacity planning process, but > not a particular use case. Such description is outside the scope > of the use case document. >=20 > E.g., section 5.1.2.2.1 goes into comparison between the scheme > where traffic engineering is done by distributed CSPF and the scheme > where it is done by using centralized computation for dynamically > setting/adjusting IGP metrics based on the traffic load and for > computing paths for explicitly routed tunnels. Such comparison is > outside the scope of the use case document. >=20 > Yakov. >=20 From nobody Thu Apr 3 13:49: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 E24A21A0186 for ; Thu, 3 Apr 2014 13:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0b1wdmdo0zkG for ; Thu, 3 Apr 2014 13:49:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C6B8D1A01D9 for ; Thu, 3 Apr 2014 13:48:57 -0700 (PDT) X-AuditID: c6180641-b7f768e000001855-62-533dc64d3363 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 43.57.06229.D46CD335; Thu, 3 Apr 2014 22:36:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 3 Apr 2014 16:48:52 -0400 From: Gregory Mirsky To: Pierre Francois Thread-Topic: [spring] Mail regarding draft-francois-spring-resiliency-use-case Thread-Index: Ac9N3QNGura6Un3pQQOXyEFX3eEwwAAKVjgAAF13p/A= Date: Thu, 3 Apr 2014 20:48:50 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78D8D4@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B78CC6F@eusaamb103.ericsson.se> In-Reply-To: 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_7347100B5761DC41A166AC17F22DF1121B78D8D4eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPiK7vMdtgg1NvFSy27XrIYvHm3R82 i+MXfjM6MHssWfKTyeP72mvMHl8uf2YLYI7isklJzcksSy3St0vgylh0ga9gQm3F8p4tLA2M Dyq7GDk5JARMJJZ83MQOYYtJXLi3nq2LkYtDSOAoo8TXVfvBEkICyxglLj7nAbHZBIwkXmzs AYuLCOhLPNl8gR2kgVlgEaPExu07mUESwgIBElfWvmKGKAqUaNz1CmgqB5BtJbH6bRlImEVA RWL7qjMsIDavgK/Ela8PGSEWNzBKnJp5kwmknlPAVuL4dyWQGkag476fWsMEYjMLiEvcejKf CeJoAYkle84zQ9iiEi8f/2OFsBUl9vVPZwcZwyyQL/F6vzbEKkGJkzOfsExgFJ2FZNIshKpZ SKogwpoS63fpQ1QrSkzpfsgOYWtItM6Zy44svoCRfRUjR2lxalluupHhJkZghB2TYHPcwbjg k+UhRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MKrcVTI7dOafa217anPs 6W8hdxInvF8/jTspSFajlGtulkFG+YrEpEf34v+dbai8E/bqKtP2sxeDFLQVSzMuTP4e3qUo GPxh/iOBHYnceTfKYnV3/H19JnXacuZn2x/Wvne2jP36PtDgmGWL8gqh1CVrsiTF4i0Zvmzx m2B/XHNZx7dIs+CEOiWW4oxEQy3mouJEAFOraw9+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/spring/2bbGZkcrMJOmXeJtCQR9Hv67QWc Cc: "spring@ietf.org" , "draft-francois-spring-resiliency-use-case@tools.ietf.org" Subject: Re: [spring] Mail regarding draft-francois-spring-resiliency-use-case 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, 03 Apr 2014 20:49:07 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78D8D4eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGllcnJlLA0KY2xpcHBlZCB0aGluZ3Mgd2XigJl2ZSBhbHJlYWR5IGFncmVlZCBvbi4gQWRk ZWQgbm90ZSB1bmRlciBHSU0+PiB0YWcuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCltzbmlwXQ0KDQoNCm8gICBEb2Vz IGxvY2FsIHByb3RlY3Rpb24gaW4gU1BSSU5HIG5ldHdvcmsgZG9tYWluIHRha2VzIGludG8gY29u c2lkZXJhdGlvbiBTSUQgbGFiZWxzLiBJZiBTSUQgbGFiZWxzIGFyZSBub3QgYmVpbmcgY29uc2lk ZXJlZCB3aGVuIHByZS1jYWxjdWxhdGluZyBiYWNrdXAgdHVubmVscyB0aGVuIGl0IGlzIHBvc3Np YmxlIHRoYXQgYWZ0ZXIgdGhlIHN3aXRjaG92ZXIgZW5kLXRvLWVuZCBwYXRoIGZhaWxzLiBPbiB0 aGUgb3RoZXIgaGFuZCwgaWYgU0lEIGxhYmVscyBiZWluZyBjb25zaWRlcmVkLCB0aGVuLCBpbiBn ZW5lcmFsIGNhc2UsIGludGVybWVkaWF0ZSBub2RlIG11c3QgbWFpbnRhaW4gcGF0aCBpbmZvcm1h dGlvbiwgd2hpY2ggaXMgbm90IGFzIFNlZ21lbnQgUm91dGluZyBwYXJhZGlnbSBiZWluZyBkZWZp bmVkIGF0IHRoaXMgdGltZS4NCg0KDQpXZWxsIG5vdyB0aGF0IHRoZSBkcmFmdCBpcyBub3QgYWJv dXQgc29sdXRpb25zIG9yIHNwZWNpZmljcyBvZiBTUiwgdGhpcyBpcyBub3QgYSBwcm9ibGVtIGFu eW1vcmUgOikNCg0KTW9yZSBzZXJpb3VzbHksIHllcywgaW4gU1IsIHlvdSBoYXZlIHRvIHBheSBh dHRlbnRpb24gdG8gbGFiZWwgYWxsb2NhdGlvbiB3aGVuIGluc3RhbGxpbmcgeW91ciBmYWlsb3Zl ciBlbnRyaWVzIGluIHRoZSBGSUIuIEhvd2V2ZXIgSSBkbyBub3Qgc2VlIHdoeSBpdCBsZWFkcyB0 byBoYXZpbmcgaW50ZXJtZWRpYXRlIG5vZGVzIG1haW50YWluIHBhdGggaW5mb3JtYXRpb24uDQpD YW4geW91IGV4cGFuZCBvbiB0aGlzIHBhcnQgb2YgeW91ciBjb21tZW50Pw0KDQpHSU0+PiBMaW5r IG1vZGUgb2YgbG9jYWwgcHJvdGVjdGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueSBzcGVjaWFsIGNv bnNpZGVyYXRpb24gYXMgdGhlIE1QIGlzIHRoZSBzYW1lIG5leHQtaG9wIG5vZGUgb2YgdGhlIHBy b3RlY3RlZCBsaW5rLiBCdXQgZm9yIG5vZGUgbW9kZSBvZiBsb2NhbCBwcm90ZWN0aW9uIHNwZWNp YWwgY29uc2lkZXJhdGlvbiBtdXN0IGJlIGdpdmVuIGlmIFNJRCBmdW5jdGlvbmFsaXR5IHRvIGJl IHVzZWQuIENvbnNpZGVyIGNhc2Ugd2hlbiB0aGUgbmV4dC1ob3Agbm9kZSBoYXMgYWR2ZXJ0aXNl ZCBTSUQgdGhhdCBpcyB1c2VkIGJ5IHNvbWUgZTJlIHBhdGhzIHRoYXQgdHJhdmVyc2UgdGhlIFBM UiBhbmQgdGhpcyBub2RlLiBBcyByZXN1bHQsIElNTywgc2VsZWN0aW9uIG9mIHRoZSBNUCBkZXBl bmRzIG5vdCBvbmx5IG9uIG5leHQtbmV4dC1ob3Agbm9kZSBvZiB0aGUgU1IgcGF0aCBidXQgb24g YXZhaWxhYmlsaXR5IG9mIHBhcnRpY3VsYXIgU0lEIGFzIHdlbGwuIE5vdyB3ZSBjYW4gbWFrZSBp dCBtb3JlIGNvbXBsZXggaWYgdGhlIHByb3RlY3RlZCBub2RlIG93bnMgbm90IG9uZSBidXQgc2V2 ZXJhbCBTSURzLiBJIHRoaW5rIHRoYXQgd2UgbWF5IGVhc2lseSBhdm9pZCB0aGlzIGNvbXBsZXhp dHkvbWVzcyBieSBzdGF0aW5nIHRoYXQgb25seSBsaW5rIG1vZGUgbG9jYWwgcHJvdGVjdGlvbiBp cyBhcHBsaWNhYmxlIHRvIFNQUklORyBkb21haW5zIGFuZCBsZWF2ZSBzZXJ2aWNlIHByb3RlY3Rp b24vcmVkdW5kYW5jeSB0byBTZXJ2aWNlL1NGQyBPQU0gbGF5ZXIuDQoNCkNoZWVycywNCg0KUGll cnJlLg0KDQoNClJlZ2FyZHMsDQogICAgICAgICAgICAgICAgR3JlZw0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNw cmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_7347100B5761DC41A166AC17F22DF1121B78D8D4eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjY1Mzg3MDcyMzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTIwNzYwMzE3MTAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5IaSBQaWVycmUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmNsaXBwZWQgdGhpbmdzIHdl4oCZdmUgYWxy ZWFkeSBhZ3JlZWQgb24uIEFkZGVkIG5vdGUgdW5kZXIgR0lNJmd0OyZndDsgdGFnLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b c25pcF08bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPkRvZXMgbG9jYWwgcHJvdGVjdGlvbiBpbiBTUFJJTkcgbmV0d29y ayBkb21haW4gdGFrZXMgaW50byBjb25zaWRlcmF0aW9uIFNJRCBsYWJlbHMuIElmIFNJRCBsYWJl bHMgYXJlIG5vdCBiZWluZyBjb25zaWRlcmVkIHdoZW4gcHJlLWNhbGN1bGF0aW5nIGJhY2t1cCB0 dW5uZWxzIHRoZW4gaXQgaXMgcG9zc2libGUgdGhhdCBhZnRlciB0aGUgc3dpdGNob3ZlciBlbmQt dG8tZW5kIHBhdGggZmFpbHMuDQogT24gdGhlIG90aGVyIGhhbmQsIGlmIFNJRCBsYWJlbHMgYmVp bmcgY29uc2lkZXJlZCwgdGhlbiwgaW4gZ2VuZXJhbCBjYXNlLCBpbnRlcm1lZGlhdGUgbm9kZSBt dXN0IG1haW50YWluIHBhdGggaW5mb3JtYXRpb24sIHdoaWNoIGlzIG5vdCBhcyBTZWdtZW50IFJv dXRpbmcgcGFyYWRpZ20gYmVpbmcgZGVmaW5lZCBhdCB0aGlzIHRpbWUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XZWxsIG5vdyB0aGF0IHRo ZSBkcmFmdCBpcyBub3QgYWJvdXQgc29sdXRpb25zIG9yIHNwZWNpZmljcyBvZiBTUiwgdGhpcyBp cyBub3QgYSBwcm9ibGVtIGFueW1vcmUgOikmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+TW9yZSBz ZXJpb3VzbHksIHllcywgaW4gU1IsIHlvdSBoYXZlIHRvIHBheSBhdHRlbnRpb24gdG8gbGFiZWwg YWxsb2NhdGlvbiB3aGVuIGluc3RhbGxpbmcgeW91ciBmYWlsb3ZlciBlbnRyaWVzIGluIHRoZSBG SUIuIEhvd2V2ZXIgSSBkbyBub3Qgc2VlIHdoeSBpdCBsZWFkcyB0byBoYXZpbmcNCiBpbnRlcm1l ZGlhdGUgbm9kZXMgbWFpbnRhaW4gcGF0aCBpbmZvcm1hdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPkNhbiB5b3UgZXhwYW5kIG9uIHRoaXMgcGFydCBvZiB5b3Vy IGNvbW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5HSU0mZ3Q7Jmd0OyBMaW5rIG1vZGUgb2YgbG9jYWwgcHJv dGVjdGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueSBzcGVjaWFsIGNvbnNpZGVyYXRpb24gYXMgdGhl IE1QIGlzIHRoZSBzYW1lIG5leHQtaG9wIG5vZGUgb2YgdGhlIHByb3RlY3RlZCBsaW5rLiBCdXQg Zm9yIG5vZGUgbW9kZSBvZiBsb2NhbCBwcm90ZWN0aW9uIHNwZWNpYWwgY29uc2lkZXJhdGlvbiBt dXN0IGJlIGdpdmVuDQogaWYgU0lEIGZ1bmN0aW9uYWxpdHkgdG8gYmUgdXNlZC4gQ29uc2lkZXIg Y2FzZSB3aGVuIHRoZSBuZXh0LWhvcCBub2RlIGhhcyBhZHZlcnRpc2VkIFNJRCB0aGF0IGlzIHVz ZWQgYnkgc29tZSBlMmUgcGF0aHMgdGhhdCB0cmF2ZXJzZSB0aGUgUExSIGFuZCB0aGlzIG5vZGUu IEFzIHJlc3VsdCwgSU1PLCBzZWxlY3Rpb24gb2YgdGhlIE1QIGRlcGVuZHMgbm90IG9ubHkgb24g bmV4dC1uZXh0LWhvcCBub2RlIG9mIHRoZSBTUiBwYXRoIGJ1dCBvbiBhdmFpbGFiaWxpdHkNCiBv ZiBwYXJ0aWN1bGFyIFNJRCBhcyB3ZWxsLiBOb3cgd2UgY2FuIG1ha2UgaXQgbW9yZSBjb21wbGV4 IGlmIHRoZSBwcm90ZWN0ZWQgbm9kZSBvd25zIG5vdCBvbmUgYnV0IHNldmVyYWwgU0lEcy4gSSB0 aGluayB0aGF0IHdlIG1heSBlYXNpbHkgYXZvaWQgdGhpcyBjb21wbGV4aXR5L21lc3MgYnkgc3Rh dGluZyB0aGF0IG9ubHkgbGluayBtb2RlIGxvY2FsIHByb3RlY3Rpb24gaXMgYXBwbGljYWJsZSB0 byBTUFJJTkcgZG9tYWlucyBhbmQgbGVhdmUNCiBzZXJ2aWNlIHByb3RlY3Rpb24vcmVkdW5kYW5j eSB0byBTZXJ2aWNlL1NGQyBPQU0gbGF5ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5QaWVy cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3Jl ZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B78D8D4eusaamb103erics_-- From nobody Thu Apr 3 14:02: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 69EB61A0181 for ; Thu, 3 Apr 2014 14:02:08 -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 NJVinwYjhVQb for ; Thu, 3 Apr 2014 14:02:03 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9731A0172 for ; Thu, 3 Apr 2014 14:02:03 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rl12so2480167iec.36 for ; Thu, 03 Apr 2014 14:01:58 -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=hYifPErvoh4rgrakcVQSryK2yeWQPKVmcSiSnmeIeOo=; b=RSPqwk5ezaDMtTw6PsERXLrGJQGe6KmxCSDSBA6C2w3VF2n2k720Ioc45nITV3orb2 NIlxSLHPkX9tcbhsIALUjczoQrnVFKIlxgLhxxPAu+30Q80UWedgUd2oiTPBLS/rQkT1 Voz4QbAdsFIdtOzxwwk2ejFQ9rs2meI0SoB+uHi9JeMVgMKvfHYw51p6JArkoAKsJmBE O3eGynH1znq9hk6iI90nexCInCAznQekDhXaxw38aij+hLQcTcgb4BrxVeSG6dhfsSET vx9h7SAOCm6BZXSWd9wXXpU5h1SP2uN9xyu2p6oN5rrDEfA1a47EDMxoADGgeKtu0yT1 /mbQ== MIME-Version: 1.0 X-Received: by 10.50.13.100 with SMTP id g4mr17752971igc.9.1396558918818; Thu, 03 Apr 2014 14:01:58 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Thu, 3 Apr 2014 14:01:58 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B78D8D4@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B78CC6F@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B78D8D4@eusaamb103.ericsson.se> Date: Thu, 3 Apr 2014 23:01:58 +0200 X-Google-Sender-Auth: snNgz9d1WEAIGoyQ6pRJYI-E0vg Message-ID: From: Robert Raszuk To: Gregory Mirsky Content-Type: multipart/alternative; boundary=089e013c661443a17804f629b609 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ZAcBdlJECEznJLmN_mvNDJy78qs Cc: Pierre Francois , "spring@ietf.org" , "draft-francois-spring-resiliency-use-case@tools.ietf.org" Subject: Re: [spring] Mail regarding draft-francois-spring-resiliency-use-case 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, 03 Apr 2014 21:02:08 -0000 --089e013c661443a17804f629b609 Content-Type: text/plain; charset=ISO-8859-1 Hi Greg & Pierre, More seriously, yes, in SR, you have to pay attention to label allocation > when installing your failover entries in the FIB. However I do not see why > it leads to having intermediate nodes maintain path information. > > Can you expand on this part of your comment? > > > > GIM>> Link mode of local protection does not require any special > consideration as the MP is the same next-hop node of the protected link. > But for node mode of local protection special consideration must be given > if SID functionality to be used. Consider case when the next-hop node has > advertised SID that is used by some e2e paths that traverse the PLR and > this node. As result, IMO, selection of the MP depends not only on > next-next-hop node of the SR path but on availability of particular SID as > well. Now we can make it more complex if the protected node owns not one > but several SIDs. I think that we may easily avoid this complexity/mess by > stating that only link mode local protection is applicable to SPRING > domains and leave service protection/redundancy to Service/SFC OAM layer. > I think you are both right :) I think what Greg you are refering to is state of the repair "paths" in regards to IGP topology which clearly is required by all node protection solutions. Contrary what I think Pierre consider as "path" is the end to end traffic flow paths which would normally result in 100s or 1000s LSPs state - that clearly is not required in SR node protection. So what may be helpful is to rather then overloading term "path" here redefine it for the purpose of this discussion into IGP topology state (as example). Cheers, R. --089e013c661443a17804f629b609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Greg & Pierre,

More seriously, yes, in SR, you have= to pay attention to label allocation when installing your failover entries= in the FIB. However I do not see why it leads to having intermediate nodes maintain path information.=A0

Can you expand on this part of your = comment?

=A0

GIM>> Link mode = of local protection does not require any special consideration as the MP is= the same next-hop node of the protected link. But for node mode of local p= rotection special consideration must be given if SID functionality to be used. Consider case when the next-hop node has = advertised SID that is used by some e2e paths that traverse the PLR and thi= s node. As result, IMO, selection of the MP depends not only on next-next-h= op node of the SR path but on availability of particular SID as well. Now we can make it more complex if the protecte= d node owns not one but several SIDs. I think that we may easily avoid this= complexity/mess by stating that only link mode local protection is applica= ble to SPRING domains and leave service protection/redundancy to Service/SFC OAM layer.



I think you are both right :)=A0

I think what Greg you are refering to is state of the repair "paths&qu= ot; in regards to IGP topology which clearly is required by all node protec= tion solutions.=A0

Contrary what I think Pierre consider as = "path" is the end to end traffic flow paths which would normally = result in 100s or 1000s LSPs state - that clearly is not required in SR nod= e protection.=A0

So what may be he= lpful is to rather then overloading term "path" here redefine it = for the purpose of this discussion into IGP topology state (as example).

Cheers,
R.





=A0
--089e013c661443a17804f629b609-- From nobody Fri Apr 4 02:17: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 BFE271A001D for ; Fri, 4 Apr 2014 02:17:33 -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 eGJR452OgruI for ; Fri, 4 Apr 2014 02:17:29 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 62BD91A011A for ; Fri, 4 Apr 2014 02:17:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id E23221BA9B0; Fri, 4 Apr 2014 11:16:04 +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 Zv6E5d9hUjbs; Fri, 4 Apr 2014 11:16:04 +0200 (CEST) Received: from [192.168.1.33] (63.Red-2-136-91.dynamicIP.rima-tde.net [2.136.91.63]) (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 668031BA9AF; Fri, 4 Apr 2014 11:16:04 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8B9E8552-D3D9-4968-8D2B-7C49A010E814" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pierre Francois In-Reply-To: Date: Fri, 4 Apr 2014 11:17:23 +0200 Message-Id: References: <7347100B5761DC41A166AC17F22DF1121B78CC6F@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B78D8D4@eusaamb103.ericsson.se> To: Robert Raszuk X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/IJ5zwPrfxqS5jI5WxUnvjdIP3Ho Cc: Gregory Mirsky , "spring@ietf.org" , "draft-francois-spring-resiliency-use-case@tools.ietf.org" Subject: Re: [spring] Mail regarding draft-francois-spring-resiliency-use-case 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, 04 Apr 2014 09:17:34 -0000 --Apple-Mail=_8B9E8552-D3D9-4968-8D2B-7C49A010E814 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Robert,=20 Thanks for the clarification :) Greg,=20 There are operators who want to have the network provide such = protection.=20 You mind if I leave such approaches in the use-case doc, and we re-raise = such very relevant complexity/mess questions when solution drafts are discussed? Cheers,=20 Pierre. On Apr 3, 2014, at 11:01 PM, Robert Raszuk wrote: > Hi Greg & Pierre, >=20 > More seriously, yes, in SR, you have to pay attention to label = allocation when installing your failover entries in the FIB. However I = do not see why it leads to having intermediate nodes maintain path = information.=20 >=20 > Can you expand on this part of your comment? >=20 > =20 >=20 > GIM>> Link mode of local protection does not require any special = consideration as the MP is the same next-hop node of the protected link. = But for node mode of local protection special consideration must be = given if SID functionality to be used. Consider case when the next-hop = node has advertised SID that is used by some e2e paths that traverse the = PLR and this node. As result, IMO, selection of the MP depends not only = on next-next-hop node of the SR path but on availability of particular = SID as well. Now we can make it more complex if the protected node owns = not one but several SIDs. I think that we may easily avoid this = complexity/mess by stating that only link mode local protection is = applicable to SPRING domains and leave service protection/redundancy to = Service/SFC OAM layer. >=20 >=20 >=20 > I think you are both right :)=20 >=20 > I think what Greg you are refering to is state of the repair "paths" = in regards to IGP topology which clearly is required by all node = protection solutions.=20 >=20 > Contrary what I think Pierre consider as "path" is the end to end = traffic flow paths which would normally result in 100s or 1000s LSPs = state - that clearly is not required in SR node protection.=20 >=20 > So what may be helpful is to rather then overloading term "path" here = redefine it for the purpose of this discussion into IGP topology state = (as example). >=20 > Cheers, > R. >=20 >=20 >=20 >=20 >=20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_8B9E8552-D3D9-4968-8D2B-7C49A010E814 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 robert@raszuk.net> = wrote:

Hi Greg = & Pierre,

More seriously, yes, in SR, you have to = pay attention to label allocation when installing your failover entries = in the FIB. However I do not see why it leads to having intermediate nodes maintain path = information. 

Can you expand on this part of your = comment?

 

GIM>> Link = mode of local protection does not require any special consideration as = the MP is the same next-hop node of the protected link. But for node = mode of local protection special consideration must be given if SID functionality to be used. Consider case when the next-hop node = has advertised SID that is used by some e2e paths that traverse the PLR = and this node. As result, IMO, selection of the MP depends not only on = next-next-hop node of the SR path but on availability of particular SID as well. Now we can make it more complex if the = protected node owns not one but several SIDs. I think that we may easily = avoid this complexity/mess by stating that only link mode local = protection is applicable to SPRING domains and leave service protection/redundancy to Service/SFC OAM = layer.



I think you are both right :) 

I think what Greg you are refering to is state of the repair "paths" in = regards to IGP topology which clearly is required by all node protection = solutions. 

Contrary what I think Pierre consider as = "path" is the end to end traffic flow paths which would normally result = in 100s or 1000s LSPs state - that clearly is not required in SR node = protection. 

So what = may be helpful is to rather then overloading term "path" here redefine = it for the purpose of this discussion into IGP topology state (as = example).

Cheers,
R.





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

= --Apple-Mail=_8B9E8552-D3D9-4968-8D2B-7C49A010E814-- From nobody Fri Apr 4 10:11: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 CB43E1A0224 for ; Fri, 4 Apr 2014 10:11: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 JBY-JfHPKJzu for ; Fri, 4 Apr 2014 10:11:47 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78C1A01F3 for ; Fri, 4 Apr 2014 10:11:46 -0700 (PDT) X-AuditID: c6180641-b7f768e000001855-e9-533ee4e293ca Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C3.C4.06229.2E4EE335; Fri, 4 Apr 2014 18:59:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 4 Apr 2014 13:11:37 -0400 From: Gregory Mirsky To: Pierre Francois , Robert Raszuk Thread-Topic: [spring] Mail regarding draft-francois-spring-resiliency-use-case Thread-Index: Ac9N3QNGura6Un3pQQOXyEFX3eEwwAAKVjgAAF13p/AACU/tAAAZryOAAAgTL4A= Date: Fri, 4 Apr 2014 17:11:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78DE59@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B78CC6F@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B78D8D4@eusaamb103.ericsson.se> In-Reply-To: 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_7347100B5761DC41A166AC17F22DF1121B78DE59eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPrO7jJ3bBBjNbBC227XrIYvHm3R82 i6aFTcwWxy/8ZnRg8Viy5CeTx/e115g9dm9cwOTx5fJntgCWKC6blNSczLLUIn27BK6M95uW MRV8SK/Y8EqhgXFJVBcjJ4eEgInE0vXX2SBsMYkL99YD2VwcQgJHGSXuvvnBAuEsY5T4MHEH K0gVm4CRxIuNPewgtohAiETjwe1MIEXMAosYJfbMvw5WJCwQIHFl7StmiKJAicZdr9ggbD+J J+eegtWwCKhIzD0wlwXE5hXwlWjY+Bxq2z4miV97/oA1cArYSqx78xmsiBHovu+n1jCB2MwC 4hK3nsxngrhbQGLJnvPMELaoxMvH/1ghbEWJff3T2SHq8yVWnjrDDrFMUOLkzCcsExhFZyEZ NQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR4SZGYAQek2Bz 3MG44JPlIUZpDhYlcd4vb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAuvr7OZcG83rjv D9tsC6f2lnc0GxZ+8j+jddm89+LXVcuLZi8JWy6i4h4zaQtnv5zKF//mC/MqVA6KLlUOWGm2 vtDq6hmVyCDv2SlsOk+fs/zmnKutz+Swml0g19Pn0tLbwgvPHltaVnSh+4GmuenJBi+DCGEu +WB90a/PVspHPBXYFOv/Z4ISS3FGoqEWc1FxIgD/D8z+jgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/spring/GwYDg32fHZbB-EmJIRVCzxtPZho Cc: "spring@ietf.org" , "draft-francois-spring-resiliency-use-case@tools.ietf.org" Subject: Re: [spring] Mail regarding draft-francois-spring-resiliency-use-case 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, 04 Apr 2014 17:11:53 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78DE59eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pierre, agree, it does make sense to have local protection use case(s). We can get = into more details in requirements and draw conclusions with gap analysis do= c. Regards, Greg From: Pierre Francois [mailto:pierre.francois@imdea.org] Sent: Friday, April 04, 2014 2:17 AM To: Robert Raszuk Cc: Gregory Mirsky; spring@ietf.org; draft-francois-spring-resiliency-use-c= ase@tools.ietf.org Subject: Re: [spring] Mail regarding draft-francois-spring-resiliency-use-c= ase Robert, Thanks for the clarification :) Greg, There are operators who want to have the network provide such protection. You mind if I leave such approaches in the use-case doc, and we re-raise su= ch very relevant complexity/mess questions when solution drafts are discussed? Cheers, Pierre. On Apr 3, 2014, at 11:01 PM, Robert Raszuk > wrote: Hi Greg & Pierre, More seriously, yes, in SR, you have to pay attention to label allocation w= hen installing your failover entries in the FIB. However I do not see why i= t leads to having intermediate nodes maintain path information. Can you expand on this part of your comment? GIM>> Link mode of local protection does not require any special considerat= ion as the MP is the same next-hop node of the protected link. But for node= mode of local protection special consideration must be given if SID functi= onality to be used. Consider case when the next-hop node has advertised SID= that is used by some e2e paths that traverse the PLR and this node. As res= ult, IMO, selection of the MP depends not only on next-next-hop node of the= SR path but on availability of particular SID as well. Now we can make it = more complex if the protected node owns not one but several SIDs. I think t= hat we may easily avoid this complexity/mess by stating that only link mode= local protection is applicable to SPRING domains and leave service protect= ion/redundancy to Service/SFC OAM layer. I think you are both right :) I think what Greg you are refering to is state of the repair "paths" in reg= ards to IGP topology which clearly is required by all node protection solut= ions. Contrary what I think Pierre consider as "path" is the end to end traffic f= low paths which would normally result in 100s or 1000s LSPs state - that cl= early is not required in SR node protection. So what may be helpful is to rather then overloading term "path" here redef= ine it for the purpose of this discussion into IGP topology state (as examp= le). Cheers, R. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_7347100B5761DC41A166AC17F22DF1121B78DE59eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pierre,

agree, it does make sense= to have local protection use case(s). We can get into more details in requ= irements and draw conclusions with gap analysis doc.

 <= /p>

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

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

 <= /p>

From: Pierre F= rancois [mailto:pierre.francois@imdea.org]
Sent: Friday, April 04, 2014 2:17 AM
To: Robert Raszuk
Cc: Gregory Mirsky; spring@ietf.org; draft-francois-spring-resilienc= y-use-case@tools.ietf.org
Subject: Re: [spring] Mail regarding draft-francois-spring-resilienc= y-use-case

 

Robert, 

 

Thanks for the clarification :)

 

Greg, 

 

There are operators who want to have the network pro= vide such protection. 

You mind if I leave such approaches in the use-case = doc, and we re-raise such very relevant complexity/mess questions

when solution drafts are discussed?

 

Cheers, 

 

Pierre.

 

On Apr 3, 2014, at 11:01 PM, Robert Raszuk <robert@raszuk.net> wrote:=



= Hi Greg & Pierre,

=  

More seriously, yes, in SR, you have to pay attention to label all= ocation when installing your failover entries in the FIB. However I do not = see why it leads to having intermediate nodes maintain path information. 

Can you expand on this part of your comment?

 

GIM>> Link mode of local prote= ction does not require any special consideration as the MP is the same next= -hop node of the protected link. But for node mode of local protection special consideration must be given if SID functi= onality to be used. Consider case when the next-hop node has advertised SID= that is used by some e2e paths that traverse the PLR and this node. As res= ult, IMO, selection of the MP depends not only on next-next-hop node of the SR path but on availability of parti= cular SID as well. Now we can make it more complex if the protected node ow= ns not one but several SIDs. I think that we may easily avoid this complexi= ty/mess by stating that only link mode local protection is applicable to SPRING domains and leave service pr= otection/redundancy to Service/SFC OAM layer.

 

 

= I think you are both right :) 

=  

= I think what Greg you are refering to is state of the repair "paths&qu= ot; in regards to IGP topology which clearly is required by all node protec= tion solutions. 

=  

= Contrary what I think Pierre consider as "path" is the end to end= traffic flow paths which would normally result in 100s or 1000s LSPs state= - that clearly is not required in SR node protection. 

=  

= So what may be helpful is to rather then overloading term "path" = here redefine it for the purpose of this discussion into IGP topology state= (as example).

=  

= Cheers,

= R.

=  

=  

 

 

 

 

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

 

--_000_7347100B5761DC41A166AC17F22DF1121B78DE59eusaamb103erics_-- From nobody Fri Apr 4 11:55: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 3DA2D1A0572 for ; Fri, 4 Apr 2014 11:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pYXeIx0qLG75 for ; Fri, 4 Apr 2014 11:55:11 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6443F1A0574 for ; Fri, 4 Apr 2014 11:55:11 -0700 (PDT) Received: from mail97-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 18:55:03 +0000 Received: from mail97-tx2 (localhost [127.0.0.1]) by mail97-tx2-R.bigfish.com (Postfix) with ESMTP id 4DE36C034E; Fri, 4 Apr 2014 18:55:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzc2hzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail97-tx2: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail97-tx2 (localhost.localdomain [127.0.0.1]) by mail97-tx2 (MessageSwitch) id 1396637702680039_7610; Fri, 4 Apr 2014 18:55:02 +0000 (UTC) Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.245]) by mail97-tx2.bigfish.com (Postfix) with ESMTP id 912583800A5; Fri, 4 Apr 2014 18:55:02 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 18:54:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 4 Apr 2014 11:55:02 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s34IsoV78171; Fri, 4 Apr 2014 11:54:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404041854.s34IsoV78171@magenta.juniper.net> To: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63449.1396637690.1@juniper.net> Date: Fri, 4 Apr 2014 11:54:50 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/R_k5ehB6A3U-LLHrcMqA-sRpWKY Cc: spring@ietf.org Subject: [spring] use case vs requirements 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, 04 Apr 2014 18:55:16 -0000 Alvaro and John, The SPRING WG charter asks for "One or more documents describing SPRING use cases". Give that, could you, as the SPRING WG co-chairs, comment on whether the SPRING use cases document(s) should cover just the use cases, or should also include the SPRING architecture requirements. Yakov. From nobody Fri Apr 4 12:16: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 AC2C11A022B for ; Fri, 4 Apr 2014 12:16:25 -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 OEY2enR1K1MI for ; Fri, 4 Apr 2014 12:16:21 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id C8F3B1A0192 for ; Fri, 4 Apr 2014 12:16:21 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h18so1337893igc.14 for ; Fri, 04 Apr 2014 12:16:17 -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=PkrZMolL3ITXHrWRoy07qnTMVUH7FcmSCvejzQgBKQU=; b=SJ3R+lDpfKT72iuFEARArRxuLLX4IOkwjCV9G8NisU1B3MmleGtsYTpG9PjePzTt+i j3XwI+7vK9+J2ICGAGu2XJFSjiJ9woZNq3XEO5SN/yWu7mrVDQCX4midsTOMfw/Cuh4u 7hWAkZkxTTSSCn/mAfNprjT9vU3LUldEGaqV6STlEEwNo9mB7Ouwlj9ct84aAv0vfma5 b45BMR7QJHPe81CRAJsmsNGh97Vijl6wy7EXvEcFcRC7L2OlI/0lljYkLM2JER2ZMPZu k1wmawimGzx1B6lpwP9gBqGiM1x45Qq2l7XeRqfWTN8I5ElkilN2Q528fLF1mB4rD0U6 bsNw== MIME-Version: 1.0 X-Received: by 10.50.109.230 with SMTP id hv6mr5127515igb.9.1396638977138; Fri, 04 Apr 2014 12:16:17 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 4 Apr 2014 12:16:16 -0700 (PDT) In-Reply-To: <201404041854.s34IsoV78171@magenta.juniper.net> References: <201404041854.s34IsoV78171@magenta.juniper.net> Date: Fri, 4 Apr 2014 21:16:16 +0200 X-Google-Sender-Auth: xLAaFjaS1nk2T7hsR1buc1Ma1Iw Message-ID: From: Robert Raszuk To: Yakov Rekhter Content-Type: multipart/alternative; boundary=089e013a1d8e1ca8d904f63c5a33 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/9iEy90bn7vPTc7SuvtYzasEgkXM Cc: "Alvaro Retana \(aretana\)" , "spring@ietf.org" , "John G. Scudder" Subject: Re: [spring] use case vs requirements 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, 04 Apr 2014 19:16:25 -0000 --089e013a1d8e1ca8d904f63c5a33 Content-Type: text/plain; charset=ISO-8859-1 Hi Yakov, As a WG member not a chair I would like to ask for your clarification. Let's take some other IETF's WG use case document namely LISP Traffic Engineering Use Cases document: https://tools.ietf.org/html/draft-farinacci-lisp-te-06 It covers LISP TE Use Cases using natural language of LISP architecture. Likewise SPRING use cases documents should describe use cases using SPRING architecture not be completely detached from SPRING WG charter and focus. Otherwise they may belong at best in RTGWG not in SPRING WG. Regards, R. On Fri, Apr 4, 2014 at 8:54 PM, Yakov Rekhter wrote: > Alvaro and John, > > The SPRING WG charter asks for "One or more documents describing > SPRING use cases". > > Give that, could you, as the SPRING WG co-chairs, comment on whether > the SPRING use cases document(s) should cover just the use cases, or > should also include the SPRING architecture requirements. > > Yakov. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --089e013a1d8e1ca8d904f63c5a33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yakov,

As a WG member not a chair I would like to as= k for your clarification.=A0

Let's take some other IETF's WG u= se case document namely LISP Traffic Engineering Use Cases document:=A0

https://tools.ietf.org/html/draft-farinacci-lisp-te-06<= /a>

It covers = LISP TE Use Cases using natural language of LISP architecture.=A0

Likewise SPRING u= se cases documents should describe use cases using SPRING architecture not = be completely detached from SPRING WG charter and focus.=A0

Otherwise they ma= y belong at best in RTGWG not in SPRING WG.=A0

Regards,
R.



On Fri, Apr 4, 2014 at 8:54 PM, Yakov Rekhter <yakov@juniper.net>= ; wrote:
Alvaro and John,

The SPRING WG charter asks for "One or more documents describing
SPRING use cases".

Give that, could you, as the SPRING WG co-chairs, comment on whether
the SPRING use cases document(s) should cover just the use cases, or
should also include the SPRING architecture requirements.

Yakov.

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

--089e013a1d8e1ca8d904f63c5a33-- From nobody Fri Apr 4 12:37:50 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 444EB1A0238; Fri, 4 Apr 2014 12:37: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 nBovY7g8B_bo; Fri, 4 Apr 2014 12:37:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9342B1A0174; Fri, 4 Apr 2014 12:37:39 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140404193739.20345.19365.idtracker@ietfa.amsl.com> Date: Fri, 04 Apr 2014 12:37:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ARSC07t9atKJzHwyDxBgf99sKAY Cc: spring@ietf.org Subject: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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: Fri, 04 Apr 2014 19:37: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-previdi-spring-problem-statement-02.txt Pages : 19 Date : 2014-04-04 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-previdi-spring-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-previdi-spring-problem-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-previdi-spring-problem-statement-02 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 Apr 4 12:39: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 25DFE1A0280 for ; Fri, 4 Apr 2014 12:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 0JzAhK-U-sTh for ; Fri, 4 Apr 2014 12:39:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B48161A024D for ; Fri, 4 Apr 2014 12:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2621; q=dns/txt; s=iport; t=1396640377; x=1397849977; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ogDegj0bqGjs6pP08isKy7lDcLnpPn6C1Wwnm4/+WAY=; b=RLaNqAGv4yEugOoTKPMGeyM5DaWETCAsy+KKpDenEanUT66M0t46XOt4 GX/DQiCnsQt50TkbTMJSdiAwHKPUd1slWQT9AE5lsskLSPWPdEY59ynQ6 +P+lE9D11ouwQfQj93kKDFZw54WE/HbDIMEmMFBEKI2znXsI32mMvD0sq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAPEHP1OtJA2J/2dsb2JhbABZgwY7UQa8V4c3gSQWdIIlAQEBBAEBATc0GwIBCBIGFQkQJwsXDgIEEwmHcAgF0BYXjj41BQqDGoEUBJhbgTSLP4VMgzCCKw X-IronPort-AV: E=Sophos;i="4.97,796,1389744000"; d="scan'208";a="315341965" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 04 Apr 2014 19:39:36 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s34JdaBT014595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Apr 2014 19:39:36 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.143]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 14:39:36 -0500 From: "Stefano Previdi (sprevidi)" To: " ietf.org" Thread-Topic: I-D Action: draft-previdi-spring-problem-statement-02.txt Thread-Index: AQHPUD1eFrDUroxgG0a9S1pLnNpp/5sCLooA Date: Fri, 4 Apr 2014 19:39:35 +0000 Message-ID: <99C71C5C-C367-467D-89DA-D20EA2B92A5E@cisco.com> References: <20140404193739.20345.19365.idtracker@ietfa.amsl.com> In-Reply-To: <20140404193739.20345.19365.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.193.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <114AA5619C9FF14A9AF17C17853A62BA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Ylc6X5k9NjhvSbj7ZBM1S2l9I1I Subject: Re: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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, 04 Apr 2014 19:39:46 -0000 All, this is the new version of the problem-statement draft incorporating=20 the latest comments. Thanks. s. On Apr 4, 2014, at 9:37 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Source Packet Routing in Networking Work= ing Group of the IETF. >=20 > 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-previdi-spring-problem-statement-02.txt > Pages : 19 > Date : 2014-04-04 >=20 > 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'. >=20 > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-previdi-spring-problem-statement/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-previdi-spring-problem-statement-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-spring-problem-statement= -02 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Apr 4 13:33: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 7E4111A0280; Fri, 4 Apr 2014 13:33:54 -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 a5u0Qlei8oRm; Fri, 4 Apr 2014 13:33:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 977441A013B; Fri, 4 Apr 2014 13:33:49 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140404203349.30908.19473.idtracker@ietfa.amsl.com> Date: Fri, 04 Apr 2014 13:33:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/EIrB0tGUAaLeoKJp4PTQUlpjrAc Cc: spring@ietf.org Subject: [spring] I-D Action: draft-martin-spring-segment-routing-ipv6-use-cases-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: Fri, 04 Apr 2014 20:33:54 -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 : IPv6 SPRING Use Cases Authors : John Brzozowski John Leddy Ida Leung Stefano Previdi Mark Townsley Christian Martin Clarence Filsfils Roberta Maglione Filename : draft-martin-spring-segment-routing-ipv6-use-cases-01.txt Pages : 12 Date : 2014-04-04 Abstract: Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to the SPRING node or global within the SPRING domain. SPRING allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SPRING domain. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-martin-spring-segment-routing-ipv6-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-cases-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-martin-spring-segment-routing-ipv6-use-cases-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 Apr 4 13:53: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 927A11A00EF for ; Fri, 4 Apr 2014 13:53:38 -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 MR0vE4qw-sTK for ; Fri, 4 Apr 2014 13:53:33 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 748331A002F for ; Fri, 4 Apr 2014 13:53:33 -0700 (PDT) Received: from mail132-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 20:53:23 +0000 Received: from mail132-ch1 (localhost [127.0.0.1]) by mail132-ch1-R.bigfish.com (Postfix) with ESMTP id 7898C1E0318; Fri, 4 Apr 2014 20:53:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail132-ch1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail132-ch1 (localhost.localdomain [127.0.0.1]) by mail132-ch1 (MessageSwitch) id 139664480126009_28313; Fri, 4 Apr 2014 20:53:21 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail132-ch1.bigfish.com (Postfix) with ESMTP id EC7833202C2; Fri, 4 Apr 2014 20:53:20 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 20:53:17 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 4 Apr 2014 13:53:21 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s34KrKV56940; Fri, 4 Apr 2014 13:53:20 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404042053.s34KrKV56940@magenta.juniper.net> To: "Stefano Previdi (sprevidi)" In-Reply-To: <99C71C5C-C367-467D-89DA-D20EA2B92A5E@cisco.com> References: <20140404193739.20345.19365.idtracker@ietfa.amsl.com> <99C71C5C-C367-467D-89DA-D20EA2B92A5E@cisco.com> X-MH-In-Reply-To: "Stefano Previdi (sprevidi)" message dated "Fri, 04 Apr 2014 19:39:35 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66049.1396644800.1@juniper.net> Date: Fri, 4 Apr 2014 13:53:20 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/p1bQdoqQC7-gLmbg68FOuFxndmE Cc: " ietf.org" Subject: Re: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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, 04 Apr 2014 20:53:38 -0000 Stefano, > All, > > this is the new version of the problem-statement draft incorporating > the latest comments. Section 5.1.1.2 is clearly an improvement over what was in the previous version, although some text is still problematic. Specifically, "C only installs the path via AS2 in its RIB." If it is the Adj-RIB-Out, then C wouldn't be able to advertise the path via AS3 inside AS1 (as this path is not in the Adj-RIB-Out). And if it is the Loc-RIB, then the Adj-RIB-Out would have only the path via AS2 (as the Adj-RIB-Out is populated from the Loc-RIB), and C would not be able to advertise the path via AS3 inside AS1. Either way, this would contradict the assumption that "C propagates all the paths to Z within AS1 (add-path)." You addressed one part of my comments on section 3. However, the other part of my comments on section 3 is still not addressed. Specifically, section 3 of draft-previdi-spring-problem-statement-02 still contains the following: The source-based routing model, applied to the MPLS dataplane, offers the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress PE, with or without the expression of an explicit path and without requiring forwarding plane or control plane state in intermediate nodes. The above claim about the ability to tunnel services is misleading, as VPN and VPLS services may use p2mp or (in the case of VPN) mp2mp LSPs, and providing any capability for setting up such LSPs is not in the SPRING charter. With this in mind I propose to replace the above with the following: The source-based routing model, applied to the MPLS dataplane, offers the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress PE, with or without the expression of an explicit path and without requiring forwarding plane or control plane state in intermediate nodes, but only if such tunnels are neither p2mp nor mp2mp tunnels. Yakov. From nobody Mon Apr 7 03:38:52 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 6176B1A033C for ; Mon, 7 Apr 2014 03:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 f4OAAQV04Dsc for ; Mon, 7 Apr 2014 03:38:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AC0E31A0535 for ; Mon, 7 Apr 2014 03:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2340; q=dns/txt; s=iport; t=1396867117; x=1398076717; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Xu2CPGLDaek1f9hhG7lyxc8ja43EAfMnoYTtm8JmS4=; b=geA1uYp00LE/JhC/XQy3AbvepHEHMzua2KD7oijafLpeg4IYMWniaOY6 fgnvu2Hv54OJohC12+pAwx5o8mEkJoQlQXhobfVEQe/G9Sx7BsE0cIppp kSYUr/98JpaM7dJxkBrI41yNJXgZy+UFX4JBY+KsIQKujXmR7YjflF299 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAJp/QlOtJV2b/2dsb2JhbABZgwaBEsQagSIWdIIlAQEBAwE6PwULAgEIGB4QMiUCBA6HdgjLMheOcQeDJIEUAQOYW5I/gzCCKw X-IronPort-AV: E=Sophos;i="4.97,809,1389744000"; d="scan'208";a="315743776" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 07 Apr 2014 10:38:37 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s37AcbR2002004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Apr 2014 10:38:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.90]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 05:38:36 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] I-D Action: draft-previdi-spring-problem-statement-02.txt Thread-Index: AQHPUEfum9k58PJYXUSdWeD6kK70CpsGTk2A Date: Mon, 7 Apr 2014 10:38:36 +0000 Message-ID: <10AF0D89-AFB2-4008-912D-9C2A4C58A515@cisco.com> References: <20140404193739.20345.19365.idtracker@ietfa.amsl.com> <99C71C5C-C367-467D-89DA-D20EA2B92A5E@cisco.com> <201404042053.s34KrKV56940@magenta.juniper.net> In-Reply-To: <201404042053.s34KrKV56940@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.85.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <11A70EBED1BCF842A6558845F48F26B6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/deg7YnfEvIg5CrHyAhR1yVnyaiw Cc: " ietf.org" Subject: Re: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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, 07 Apr 2014 10:38:49 -0000 Hi Yakov, On Apr 4, 2014, at 10:53 PM, Yakov Rekhter wrote: > Stefano, >=20 >> All, >>=20 >> this is the new version of the problem-statement draft incorporating=20 >> the latest comments. >=20 > Section 5.1.1.2 is clearly an improvement over what was in the > previous version, although some text is still problematic. > Specifically, "C only installs the path via AS2 in its RIB." If it > is the Adj-RIB-Out, then C wouldn't be able to advertise the path > via AS3 inside AS1 (as this path is not in the Adj-RIB-Out). And > if it is the Loc-RIB, then the Adj-RIB-Out would have only the path > via AS2 (as the Adj-RIB-Out is populated from the Loc-RIB), and C > would not be able to advertise the path via AS3 inside AS1. Either > way, this would contradict the assumption that "C propagates all > the paths to Z within AS1 (add-path)." I'll address your BGP concerns on a separate thread. > You addressed one part of my comments on section 3. it's already good to hear/read that ;-) > However, > the other part of my comments on section 3 is still not addressed. > Specifically, section 3 of draft-previdi-spring-problem-statement-02=20 > still contains the following: >=20 > The source-based routing model, applied to the MPLS dataplane, offers > the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE > to an egress PE, with or without the expression of an explicit path > and without requiring forwarding plane or control plane state in > intermediate nodes. >=20 > The above claim about the ability to tunnel services is misleading, > as VPN and VPLS services may use p2mp or (in the case of VPN) mp2mp > LSPs, and providing any capability for setting up such LSPs is not > in the SPRING charter. >=20 > With this in mind I propose to replace the above with the following: >=20 > The source-based routing model, applied to the MPLS dataplane, offers > the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE > to an egress PE, with or without the expression of an explicit path > and without requiring forwarding plane or control plane state in > intermediate nodes, but only if such tunnels are neither p2mp > nor mp2mp tunnels. fine by me, I'll incorporate your comments. Thanks. s. >=20 > Yakov. >=20 From nobody Mon Apr 7 03:39: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 7316A1A06E7 for ; Mon, 7 Apr 2014 03:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ITVQ1SeDW-lF for ; Mon, 7 Apr 2014 03:39:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 893261A033C for ; Mon, 7 Apr 2014 03:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=840; q=dns/txt; s=iport; t=1396867175; x=1398076775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b/b9vbOAr5qch/KGhPK6f6jM7S6VJ736GYi6tae3mM0=; b=ZZxGsja4MXlZUqMIXx55z1l+s2yvEFn0YuIkWneebnoAwLSRjwjcvFRE Kq/lZg1XoJebMWrfxFIE5OJX71KY/rWLQYck0vAuykQOiqowvYzP7wohf IlU+d1XJv3ocMECCneDrg9RcQfZuT4f3RHCg878IQquxiGUtlJR7kl5TJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAGV/QlOtJA2J/2dsb2JhbABZgwY7V7xjhmZRgSIWdIIlAQEBAwEBAQE3NAYFBQsCAQgSJBAnCxcOAgQOBYdxCA3LJRMEjnEHgySBFAEDmFuSP4Mwgis X-IronPort-AV: E=Sophos;i="4.97,809,1389744000"; d="scan'208";a="315767490" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP; 07 Apr 2014 10:39:35 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s37AdYMu024692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Apr 2014 10:39:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.90]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 05:39:34 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] use case vs requirements Thread-Index: AQHPUDdvOWz2I6q+10S9gaz8DLuNuZsGTraA Date: Mon, 7 Apr 2014 10:39:33 +0000 Message-ID: References: <201404041854.s34IsoV78171@magenta.juniper.net> In-Reply-To: <201404041854.s34IsoV78171@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.85.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <757F0E3BC3B9744DA7347D090B69E507@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/hwZF-1t5JHpit_plo4uGJGu5GRY Cc: "Alvaro Retana \(aretana\)" , "" , "" Subject: Re: [spring] use case vs requirements 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, 07 Apr 2014 10:39:45 -0000 Hi Yakov, I this stage of the process, I don't see why we would need to split=20 the problem-statement draft so I'd strongly suggest to keep the=20 document as it is (with all comments being addressed) and move on, knowing the support the WG already gave on this draft. Thanks. s. On Apr 4, 2014, at 8:54 PM, Yakov Rekhter wrote: > Alvaro and John, >=20 > The SPRING WG charter asks for "One or more documents describing > SPRING use cases". >=20 > Give that, could you, as the SPRING WG co-chairs, comment on whether > the SPRING use cases document(s) should cover just the use cases, or > should also include the SPRING architecture requirements. >=20 > Yakov. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Apr 7 08:28: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 981061A07D3 for ; Mon, 7 Apr 2014 08:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_LOW=-0.7, 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 sMi1MG22rKBU for ; Mon, 7 Apr 2014 08:28:22 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 56A611A0781 for ; Mon, 7 Apr 2014 08:28:09 -0700 (PDT) Received: from mail96-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Mon, 7 Apr 2014 15:27:49 +0000 Received: from mail96-va3 (localhost [127.0.0.1]) by mail96-va3-R.bigfish.com (Postfix) with ESMTP id D2F4E3C00DA; Mon, 7 Apr 2014 15:27:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zf7Iz98dI9371I1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL8275dh1de097h186068hz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail96-va3: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail96-va3 (localhost.localdomain [127.0.0.1]) by mail96-va3 (MessageSwitch) id 139688446659797_4204; Mon, 7 Apr 2014 15:27:46 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.235]) by mail96-va3.bigfish.com (Postfix) with ESMTP id E0CB31A0057; Mon, 7 Apr 2014 15:27:45 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 7 Apr 2014 15:27:46 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Apr 2014 08:27:58 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s37FRoV48652; Mon, 7 Apr 2014 08:27:55 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404071527.s37FRoV48652@magenta.juniper.net> To: "Stefano Previdi (sprevidi)" In-Reply-To: <98C691DB-13D1-49DD-9B1D-957F1693310C@cisco.com> References: <201404021746.s32HkOV18020@magenta.juniper.net> <98C691DB-13D1-49DD-9B1D-957F1693310C@cisco.com> X-MH-In-Reply-To: "Stefano Previdi (sprevidi)" message dated "Thu, 03 Apr 2014 07:46:24 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8935.1396884470.1@juniper.net> Date: Mon, 7 Apr 2014 08:27:50 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/djHUA33JDnMR3dmd2GNNHyK71A8 Cc: "" Subject: Re: [spring] Fwd: New Version Notification for draft-previdi-spring-proble m-statement-01.txt - section 5.1.2 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, 07 Apr 2014 15:28:26 -0000 Stefano, > Hi Yakov, > > indeed. It's part of a problem statement that describes how > networks are deployed today and how these network may benefit > from a SR solution. As I mentioned in my original e-mail, section 5.1.2.2.1 presents a comparison between an approach where traffic engineering is done by distributed CSPF and an approach where it is done by using centralized computation for dynamically setting/adjusting IGP metrics based on the traffic load and for computing paths for explicitly routed tunnels. Such comparison is outside the scope of the SPRING use case document, as dynamic IGP metric adjustment based on the traffic load, and the ability to reduce the number of explicitly routed tunnels are due to the centralized path computation, and are independent of SR. Yakov. > > > > So, to me, it looks the right place for this description to be. > > > s. > > > On Apr 2, 2014, at 7:46 PM, Yakov Rekhter wrote: > > Stefano, > > > > Section 5.1.2 contains plenty of material that is not use cases. > > > > E.g., section 5.1.2.1 describes capacity planning process, but > > not a particular use case. Such description is outside the scope > > of the use case document. > > > > E.g., section 5.1.2.2.1 goes into comparison between the scheme > > where traffic engineering is done by distributed CSPF and the scheme > > where it is done by using centralized computation for dynamically > > setting/adjusting IGP metrics based on the traffic load and for > > computing paths for explicitly routed tunnels. Such comparison is > > outside the scope of the use case document. > > > > Yakov. > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > From nobody Mon Apr 7 08: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 369461A0793 for ; Mon, 7 Apr 2014 08:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.211 X-Spam-Level: X-Spam-Status: No, score=-7.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_PRBLMS=2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 X3f83oAfKwyY for ; Mon, 7 Apr 2014 08:36:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 002691A07A2 for ; Mon, 7 Apr 2014 08:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2524; q=dns/txt; s=iport; t=1396885002; x=1398094602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WRFz2JbchFCSrQi4dUt4D5VYEcg/fBaN/ei4xTT3WzE=; b=VUvgVR7Rtli5M8CuohDZaqhX0njgYmVDwWg0V0auxHo2BYagV4rZmWsg PqkNlDxbgsGrALGABa6nPzhKc0Cd5pZkUAqJ30tI2Tb9rlYFpeTOT7Ct0 v29V7XWxJKATAHuu53DaZhTYePq+Mkvl6nn4+RDx5ZDQP+gPBFoSAu8A9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAH/FQlOtJV2b/2dsb2JhbABZgwY7V7xlhmZRgSUWdIIlAQEBAwEBAQE3NAkCEAIBCBgeBQsnCyUCBA4FG4dWCA3LahMEjnEHgySBFASYW5I/gXGBP4Ir X-IronPort-AV: E=Sophos;i="4.97,810,1389744000"; d="scan'208";a="33688406" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 07 Apr 2014 15:36:42 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s37FagvT006822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Apr 2014 15:36:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.90]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 10:36:41 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] Fwd: New Version Notification for draft-previdi-spring-proble m-statement-01.txt - section 5.1.2 Thread-Index: AQHPUnX4cvnKUyd1KUOKce8rzFqKSpsGnToA Date: Mon, 7 Apr 2014 15:36:41 +0000 Message-ID: <96F6542D-E8FE-4EA1-9395-191DD6FCA365@cisco.com> References: <201404021746.s32HkOV18020@magenta.juniper.net> <98C691DB-13D1-49DD-9B1D-957F1693310C@cisco.com> <201404071527.s37FRoV48652@magenta.juniper.net> In-Reply-To: <201404071527.s37FRoV48652@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.85.19] 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/ERndJ1TReagTqzWLTuhJMpQ2UKY Cc: "" Subject: Re: [spring] Fwd: New Version Notification for draft-previdi-spring-proble m-statement-01.txt - section 5.1.2 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, 07 Apr 2014 15:36:57 -0000 Hi Yakov, On Apr 7, 2014, at 5:27 PM, Yakov Rekhter wrote: > Stefano, >=20 >> Hi Yakov, >>=20 >> indeed. It's part of a problem statement that describes how=20 >> networks are deployed today and how these network may benefit >> from a SR solution. >=20 > As I mentioned in my original e-mail, section 5.1.2.2.1 presents a > comparison between an approach where traffic engineering is done > by distributed CSPF and an approach where it is done by using > centralized computation for dynamically setting/adjusting IGP metrics > based on the traffic load and for computing paths for explicitly > routed tunnels. Such comparison is outside the scope of the SPRING > use case document, as dynamic IGP metric adjustment based on the > traffic load, and the ability to reduce the number of explicitly > routed tunnels are due to the centralized path computation, and are > independent of SR. If I take section 5.1, I see the following structure: 5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 7 5.1.1. Traffic Engineering without Bandwidth Admission Control . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. Traffic Engineering with Bandwidth Admission Control . . . . . . . . . . . . . . . . . . . . . . . 11 As the title of 5.1 says, it's an example on how TE is currently=20 deployed so to frame the context into which SR has to operate. s. >=20 > Yakov. >=20 >>>=20 >>=20 >> So, to me, it looks the right place for this description to be. >>=20 >>=20 >> s. >>=20 >>=20 >> On Apr 2, 2014, at 7:46 PM, Yakov Rekhter wrote: >>> Stefano, >>>=20 >>> Section 5.1.2 contains plenty of material that is not use cases. >>>=20 >>> E.g., section 5.1.2.1 describes capacity planning process, but >>> not a particular use case. Such description is outside the scope >>> of the use case document. >>>=20 >>> E.g., section 5.1.2.2.1 goes into comparison between the scheme >>> where traffic engineering is done by distributed CSPF and the scheme >>> where it is done by using centralized computation for dynamically >>> setting/adjusting IGP metrics based on the traffic load and for >>> computing paths for explicitly routed tunnels. Such comparison is >>> outside the scope of the use case document. >>>=20 >>> Yakov. >>>=20 >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >>=20 >>=20 >>=20 >=20 From nobody Tue Apr 8 08:38:59 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 C02171A042E; Tue, 8 Apr 2014 08:38:55 -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 9WpvjngSyrWw; Tue, 8 Apr 2014 08:38:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F22541A0437; Tue, 8 Apr 2014 08:38:53 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408153853.19851.60054.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 08:38:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/7RnoL0Lsqvy3TD6NywEctM_KExc Cc: spring@ietf.org Subject: [spring] I-D Action: draft-francois-spring-resiliency-use-case-02.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: Tue, 08 Apr 2014 15:38:55 -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 : Use-cases for Resiliency in SPRING Authors : Pierre Francois Clarence Filsfils Bruno Decraene Rob Shakir Filename : draft-francois-spring-resiliency-use-case-02.txt Pages : 8 Date : 2014-04-08 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-francois-spring-resiliency-use-case/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-francois-spring-resiliency-use-case-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-francois-spring-resiliency-use-case-02 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 Tue Apr 8 08:43: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 47FDC1A0461 for ; Tue, 8 Apr 2014 08:43:07 -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 iO_2411XZa8p for ; Tue, 8 Apr 2014 08:43:03 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id BFC951A03D7 for ; Tue, 8 Apr 2014 08:43:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 81DB91CAB66 for ; Tue, 8 Apr 2014 17:41:39 +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 gGroZnHFojQd for ; Tue, 8 Apr 2014 17:41:39 +0200 (CEST) Received: from ams3-vpn-dhcp4605.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 DB0261CAB65 for ; Tue, 8 Apr 2014 17:41:38 +0200 (CEST) From: Pierre Francois Content-Type: multipart/alternative; boundary="Apple-Mail=_FCEB42C8-E2DB-4335-92B1-46BCED1C6808" Date: Tue, 8 Apr 2014 17:42:59 +0200 References: <20140408153853.19851.60054.idtracker@ietfa.amsl.com> To: "spring@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/4PO9cachNMPdf2gPGSsXWLYVIjs Subject: [spring] Fwd: I-D Action: draft-francois-spring-resiliency-use-case-02.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, 08 Apr 2014 15:43:07 -0000 --Apple-Mail=_FCEB42C8-E2DB-4335-92B1-46BCED1C6808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello everyone,=20 This new version of the resiliency use case document is basically = featuring the new ToC as discussed last week with Yakov, as=20 well as the changes related to the set of comments received from Greg. Cheers,=20 Regards,=20 Pierre. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [spring] I-D Action: = draft-francois-spring-resiliency-use-case-02.txt > Date: April 8, 2014 5:38:53 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: spring@ietf.org >=20 >=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-francois-spring-resiliency-use-case-02.txt > Pages : 8 > Date : 2014-04-08 >=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-francois-spring-resiliency-use-case= / >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-francois-spring-resiliency-use-case-02 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-francois-spring-resiliency-use-ca= se-02 >=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 --Apple-Mail=_FCEB42C8-E2DB-4335-92B1-46BCED1C6808 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: [spring] I-D Action: = draft-francois-spring-resiliency-use-case-02.txt
Date: April 8, 2014 = 5:38:53 PM GMT+02:00


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
=             &n= bsp;           &nbs= p;Clarence Filsfils
=             &n= bsp;           &nbs= p;Bruno Decraene
=             &n= bsp;           &nbs= p;Rob Shakir
= Filename        : = draft-francois-spring-resiliency-use-case-02.txt
Pages =           : 8
Date =            : = 2014-04-08

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-francois-spring-resilien= cy-use-case/

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

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-francois-spring-resiliency= -use-case-02


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

= --Apple-Mail=_FCEB42C8-E2DB-4335-92B1-46BCED1C6808-- From nobody Thu Apr 10 02:13: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 DE3C11A0471 for ; Thu, 10 Apr 2014 02:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 S3FvVfRJsW0p for ; Thu, 10 Apr 2014 02:13:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8601A02F7 for ; Thu, 10 Apr 2014 02:13:02 -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 BFM06003; Thu, 10 Apr 2014 09:13:01 +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; Thu, 10 Apr 2014 10:11:55 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 10:13:00 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 17:12:57 +0800 From: Lizhenbin To: "aretana@cisco.com" Thread-Topic: [spring] Comments on Abstraction//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPVJ0Q0DjM+F7ShkS2T5ZqGTAgSQ== Date: Thu, 10 Apr 2014 09:12:57 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D082040CD@nkgeml506-mbx.china.huawei.com> References: <201403241946.s2OJjvV90789@magenta.juniper.net> In-Reply-To: <201403241946.s2OJjvV90789@magenta.juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] 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/NvffsVzRL-hMdNxJ9OBiDYC1oP8 Cc: "spring@ietf.org" Subject: [spring] Comments on Abstraction//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: Thu, 10 Apr 2014 09:13:08 -0000 Alvaro, Abstraction of draft-martin-spring-segment-routing-ipv6-use-cases presents = as follows: ' SPRING allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SPRING domain.=20 ' I wonder if now SPRING still keeps this rule. Besides node segment and link= segment for composing the explicit path, segments has being extended to ma= ny types of services and transit nodes will have to maintain more states. Regards, Zhenbin(Robin) > Hi! >=20 > This message officially starts the call for adoption for=20 > draft-martin-spring-segment-routing-ipv6-use-cases. >=20 > Please indicate your position about adopting this use cases draft by=20 > end-of-day on March 27, 2014. >=20 > http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-us > e-ca ses >=20 > Thanks! >From section 2.5: _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Apr 10 02:25:42 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 D876F1A019F for ; Thu, 10 Apr 2014 02:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 kXxifE3Vu7eA for ; Thu, 10 Apr 2014 02:25:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0992E1A01AF for ; Thu, 10 Apr 2014 02:25:38 -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 BCY36521; Thu, 10 Apr 2014 09:25:37 +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; Thu, 10 Apr 2014 10:24:31 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 10:25:37 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 17:25:33 +0800 From: Lizhenbin To: "aretana@cisco.com" Thread-Topic: [spring] Comments on Section 2//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPR5nZYQd4grj6GkqXakXA/8yL9JsKqYYggAABlvA= Date: Thu, 10 Apr 2014 09:25:33 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D082040E3@nkgeml506-mbx.china.huawei.com> References: <201403241946.s2OJjvV90789@magenta.juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] 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/TAXul2h_rTT0jD00rOpDaaEqeYo Cc: "spring@ietf.org" Subject: [spring] Comments on Section 2//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: Thu, 10 Apr 2014 09:25:41 -0000 Alvaro, Please refer to following comments regarding Section 2 of draft-martin-spri= ng-segment-routing-ipv6-use-cases ' To reach the same scale, an operator would need to introduce additional complexity, such as mechanisms described in [I-D.ietf-mpls-seamless-mpls] ' I have explained the inappropriate involvement of seamless MPLS here in pre= vious comment. Firstly maybe I need the authors explain what's the addition= al complexity. In order to cope with the scalability issue, label BGP, etc = is introduced in seamless MPLS which in my opinion it may be the only major= complexity. But it is because of the L2VPN/L3VPN which need the LSP for th= e host address. If only take into account the reachability of IP, I think u= sing MPLS can also be simple. I wonder for the same scale network like seam= less MPLS and L2VPN/L3VPN is also necessary, what is the possible solution = based on IPv6 segment routing? Complex configuration on explicit path is in= troduced for edge devices in the network. Or again, the unproved SDN soluti= on will be proposed to simplify the configuration. But how complex and diff= icult it may be to control 100,000 access nodes. ' Specifically, there are a class of use cases that motivate an IPv6 data plane. We identify some fundamental scenarios that, when recognized in conjunction, strongly indicate an IPv6 data plane: ' I would not like to lead to the debate between MPLS fans and MPLS haters. I= truly agree there exists the scenarios which only use IPv6 data plane inst= ead of MPLS data plane. But I think the text here conveys a little misleadi= ng information. It mainly justfiy IPv6 data plane instead of IPv6 segment r= outing. IPv6 data plane and IPv6 segment routing are different concepts. Wh= en debate with possible fans, we would understand what IPv6 is debating :).= According to the draft, if authors try to justify IPv6 data plane, it is e= nough to take little text to clarify it. More effort should focus on justif= ying IPv6 segment routing. ' In any environment with requirements such as those listed above, an IPv6 data plane provides a powerful combination of capabilities for a network operator to realize benefits in explicit routing, protection and restoration, high routing scalability, traffic engineering, service chaining, service differentiation and application flexibility via programmability. ' 1. In draft-previdi-spring-problem-statement, the problem statement is simp= le: fast reroute, traffic engineering.=20 2. According to draft-previdi-spring-problem-statement and RFC 2702, traffi= c engineering should includes explicit routing, protection and restoration.= =20 3. Regarding service chain, until now it has not justified its relation wit= h segment routing.=20 4. Regarding service differentiation, need clarification. If it does not re= peat service chain, according to my understanding, L2VPN/L3VPN based on MPL= S are always to differentiate services. ' In addition to the use cases described in this document the SPRING architecture can be applied to all the use cases described in [I-D.filsfils-rtgwg-segment-routing-use-cases] for the SPRING MPLS data plane, when an IPv6 data plane is present. ' I do not think it is so simple that all use cases in [I-D.filsfils-rtgwg-se= gment-routing-use-cases] can apply to IPv6 data plane directly. For example= , if the IPv6 segment routing header in draft-previdi-6man-segment-routing-= header-00 does work, at least, comparing with MPLS , it may propose securit= y concern since it will expose the whole IP address list other than the mea= ningless MPLS labels. In my opinion, the traffic engineering and fast re-ro= ute need rethinking in IPv6 environment.=20 Regards, Zhenbin(Robin) > Hi! >=20 > This message officially starts the call for adoption for=20 > draft-martin-spring-segment-routing-ipv6-use-cases. >=20 > Please indicate your position about adopting this use cases draft by=20 > end-of-day on March 27, 2014. >=20 > http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-us > e-ca ses >=20 > Thanks! >From section 2.5: _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Apr 10 02:39: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 B60121A0660 for ; Thu, 10 Apr 2014 02:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 Svu0V-TBfRTS for ; Thu, 10 Apr 2014 02:39:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D238F1A065D for ; Thu, 10 Apr 2014 02:39:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFM08948; Thu, 10 Apr 2014 09:39:05 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 10:37:32 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 10:38:49 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 17:38:46 +0800 From: Lizhenbin To: "aretana@cisco.com" Thread-Topic: [spring] Comments on Section 2.1 and 2.2//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPVKCr/QEUkY2uN0+9L+0BnJEO1A== Date: Thu, 10 Apr 2014 09:38:46 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D082040FF@nkgeml506-mbx.china.huawei.com> References: <201403241946.s2OJjvV90789@magenta.juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] 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/mvvh8QPIVhvR-hrcs25Z2STV6Mg Cc: "spring@ietf.org" Subject: [spring] Comments on Section 2.1 and 2.2//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: Thu, 10 Apr 2014 09:39:08 -0000 Alvaro, Please refer to following comments regarding Section 2.1 and 2.2 of draft-m= artin-spring-segment-routing-ipv6-use-cases These sections describe the use cases of segment routing in home network an= d access network. I would like to quote the text which concerns MPLS scalab= ility in section 2: ' 4. There is a need to connect millions of addressable segment endpoints, thus high routing scalability is a requirement. ' I am glad that authors can take into account scalability issue. But scalabi= lity will be from multiple aspects. For the scenarios of the home network a= nd access network which likes to use IPv6 segment routing, the complex conf= iguration for the explicit routing will also be a challenge on scalability.= In addition, in these scenarios, the end user is easily involved. I wonder= if the user could do or likes to do such professional path policy configur= ation. Maybe SDN is a possible solutions. But for the home network and the = access network, there maybe huge number of devices to control (e.g. 100, 00= 0 access nodes mentioned in seamless MPLS). It will also propose enough sca= lability challenge to the possible controller. From my own point of view, t= he use case proposed here is not persuasive enough until now. Regards, Zhenbin(Robin) > Hi! >=20 > This message officially starts the call for adoption for=20 > draft-martin-spring-segment-routing-ipv6-use-cases. >=20 > Please indicate your position about adopting this use cases draft by=20 > end-of-day on March 27, 2014. >=20 > http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-us > e-ca ses >=20 > Thanks! >From section 2.5: _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Apr 10 03:02: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 557711A01E6 for ; Thu, 10 Apr 2014 03:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 cGYt8tO1qVeO for ; Thu, 10 Apr 2014 03:02:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 605D61A01F1 for ; Thu, 10 Apr 2014 03:02:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY40393; Thu, 10 Apr 2014 10:02:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 11:01:06 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 11:02:23 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 18:02:18 +0800 From: Lizhenbin To: "aretana@cisco.com" Thread-Topic: [spring] Comments on Section 2.3//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPVKP0RE4LUChUlkG6cU8SUjAxXA== Date: Thu, 10 Apr 2014 10:02:17 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08204136@nkgeml506-mbx.china.huawei.com> References: <201403241946.s2OJjvV90789@magenta.juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] 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/JEzXQxqxKqXIGEOIKMj_mxEB7jw Cc: "spring@ietf.org" Subject: [spring] Comments on Section 2.3//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: Thu, 10 Apr 2014 10:02:30 -0000 Alvaro, Please refer to following comments regarding Section 2.3 of draft-martin-sp= ring-segment-routing-ipv6-use-cases These sections describe the use cases of segment routing in data center net= work. 1. I wonder if now there is a hot discussion on using IPv6 in data center. = What is the drive to introduce IPv6 into data center, lack of IP addresses? 2. Regarding "Service Function Chain", it is earlier to involve IPv6 segmen= t routing in the field. Until now, the requirement and architecture of SFC = WG is not determined yet. The solution proposed in SFC seems to prefer inde= pendent service header or reusing exiting header. Here the solution based o= n IPv6 segment routing seems only has relation with the use case described = by SFC WG. If the SFC WG is taken into account, the requirement, architectu= re, the solution in SFC WG should also be taken into account. If so, bindin= g the service chain function with a specific IP header maybe not a good cho= ice. That is, for IPv6 segment routing, it is too early to utilize advantag= e of service chain. Regards, Zhenbin(Robin) > Hi! >=20 > This message officially starts the call for adoption for=20 > draft-martin-spring-segment-routing-ipv6-use-cases. >=20 > Please indicate your position about adopting this use cases draft by=20 > end-of-day on March 27, 2014. >=20 > http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-us > e-ca ses >=20 > Thanks! >From section 2.5: _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Apr 10 09:16: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 4A0C61A0299 for ; Thu, 10 Apr 2014 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 D704BXF6psOW for ; Thu, 10 Apr 2014 09:16:22 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7470A1A0289 for ; Thu, 10 Apr 2014 09:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2935; q=dns/txt; s=iport; t=1397146582; x=1398356182; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QXL0XKNVs28AgII/OaI6eR0EJDN4TZHSDFxv3hSdfy8=; b=mBrraBEGpK5St2BUbqm+WJX1TUeddMqJA/k73PAUM943mjHzUCwO+igW dC6fFVHlxFVwpkTUjp8lcyw156C1M20UzKiyEfqAsh0A6bj2Jjb5/hJBS QhrEsG7w0G6Ri2yGi0e+iiVfP5paBtRYScd6KAtnDyjG8+41Hi9DDivGx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFABvDRlOtJA2F/2dsb2JhbABagwY7V7xxhmRRgSEWdIIlAQEBAwEBAQE3NAsFCwIBCBgeECcLJQIEDgWHdAgNzUUTBI5sB4MkgRQEmF6SQoMwgis X-IronPort-AV: E=Sophos;i="4.97,835,1389744000"; d="scan'208";a="316750148" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 10 Apr 2014 16:16:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3AGGLP4006692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Apr 2014 16:16:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 11:16:21 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] I-D Action: draft-previdi-spring-problem-statement-02.txt Thread-Index: AQHPUk2S7l1DQafXYk6N5WKrmGCSepsLX54A Date: Thu, 10 Apr 2014 16:16:20 +0000 Message-ID: <25ECC29C-53A8-454D-B51F-CE587CFEDFD4@cisco.com> References: <20140404193739.20345.19365.idtracker@ietfa.amsl.com> <99C71C5C-C367-467D-89DA-D20EA2B92A5E@cisco.com> <201404042053.s34KrKV56940@magenta.juniper.net> <10AF0D89-AFB2-4008-912D-9C2A4C58A515@cisco.com> In-Reply-To: <10AF0D89-AFB2-4008-912D-9C2A4C58A515@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.83.228] 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/57jL4shCdV2dHbcnBfIhk_rFX08 Cc: " ietf.org" Subject: Re: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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, 10 Apr 2014 16:16:24 -0000 Hi Yakov, see below a comment I forgot to answer... On Apr 7, 2014, at 12:38 PM, Stefano Previdi (sprevidi) wrote: > Hi Yakov, >=20 > On Apr 4, 2014, at 10:53 PM, Yakov Rekhter wrote: >> Stefano, >>=20 >>> All, >>>=20 >>> this is the new version of the problem-statement draft incorporating=20 >>> the latest comments. >>=20 >> Section 5.1.1.2 is clearly an improvement over what was in the >> previous version, although some text is still problematic. >> Specifically, "C only installs the path via AS2 in its RIB." If it >> is the Adj-RIB-Out, then C wouldn't be able to advertise the path >> via AS3 inside AS1 (as this path is not in the Adj-RIB-Out). And >> if it is the Loc-RIB, then the Adj-RIB-Out would have only the path >> via AS2 (as the Adj-RIB-Out is populated from the Loc-RIB), and C >> would not be able to advertise the path via AS3 inside AS1. Either >> way, this would contradict the assumption that "C propagates all >> the paths to Z within AS1 (add-path)." you're right, the statement that is confusing is "C only installs=20 the path via AS2 in its RIB". Anyway, we have re-phrased the whole section and I'm about to submit=20 a new version of the draft. Thanks. s. > I'll address your BGP concerns on a separate thread. >=20 >=20 >> You addressed one part of my comments on section 3. >=20 >=20 > it's already good to hear/read that ;-) >=20 >=20 >> However, >> the other part of my comments on section 3 is still not addressed. >> Specifically, section 3 of draft-previdi-spring-problem-statement-02=20 >> still contains the following: >>=20 >> The source-based routing model, applied to the MPLS dataplane, offers >> the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE >> to an egress PE, with or without the expression of an explicit path >> and without requiring forwarding plane or control plane state in >> intermediate nodes. >>=20 >> The above claim about the ability to tunnel services is misleading, >> as VPN and VPLS services may use p2mp or (in the case of VPN) mp2mp >> LSPs, and providing any capability for setting up such LSPs is not >> in the SPRING charter. >>=20 >> With this in mind I propose to replace the above with the following: >>=20 >> The source-based routing model, applied to the MPLS dataplane, offers >> the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE >> to an egress PE, with or without the expression of an explicit path >> and without requiring forwarding plane or control plane state in >> intermediate nodes, but only if such tunnels are neither p2mp >> nor mp2mp tunnels. >=20 >=20 > fine by me, I'll incorporate your comments. Thanks. >=20 > s. >=20 >=20 >=20 >>=20 >> Yakov. >>=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Apr 10 09:40:57 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 6F7A61A01FF for ; Thu, 10 Apr 2014 09:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 8FkooYz8ugEg for ; Thu, 10 Apr 2014 09:40:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A43A91A01DC for ; Thu, 10 Apr 2014 09:40:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY78947; Thu, 10 Apr 2014 16:40:49 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 17:39:30 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 17:40:48 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 11 Apr 2014 00:40:43 +0800 From: Lizhenbin To: "aretana@cisco.com" Thread-Topic: [spring] Comments on Section 2.4//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPVNudwNTFpH6mR0mskOx/0j4KBw== Date: Thu, 10 Apr 2014 16:40:42 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D082042C6@nkgeml506-mbx.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.45.28.248] 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/yvc3j9x3tp7KiD3e31tEG6MpSv0 Cc: "spring@ietf.org" Subject: [spring] Comments on Section 2.4//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: Thu, 10 Apr 2014 16:40:53 -0000 Alvaro, Regarding the section IPv6 Segment Routing in the Core networks, I have fol= lowing comments: In order to justify the requirement, I think it tries to romove all possibl= e options for the designed core network: -- MPLS: it is definitely be removed firstly. -- L2VPN/L3VPN: it is related with MPLS. I think it is naturally removed. T= hen the designed core network has no purpose to bear L2VPN/L3VPN service. T= he network is only for IP routing. -- IPv4: it is removed for the reason clarified by the text's self. That is= , there should be no co-existence of IPv4 and IPv6. Or else, the use cases = described for segment routing can only apply to IPv6. The network is only f= or IPv6 routing. -- Multicast: Segment routing cannot cover the use case. The multicast serv= ice should be removed. Then network is only for IPv6 unicast routing. Then I do not think the debates on the draft should not be simply blamed on= the choice between IPv6 or MPLS. I wonder how many operators perfers the d= esigned core network for IPv6 segment routing and whether it is necessary t= o introduce complex IPv6 segment routing fowarding for the limited scenario= s. Regards, Zhenbin(Robin) > Hi! > > This message officially starts the call for adoption for > draft-martin-spring-segment-routing-ipv6-use-cases. > > Please indicate your position about adopting this use cases draft by > end-of-day on March 27, 2014. > > http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-us > e-ca ses > > Thanks! >From section 2.5: _______________________________________________ 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 Thu Apr 10 15:38: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 430F21A0316 for ; Thu, 10 Apr 2014 15:38:13 -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 8UeOgN-Pg8fJ for ; Thu, 10 Apr 2014 15:38:08 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id D28371A031E for ; Thu, 10 Apr 2014 15:38:08 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id c1so96011igq.7 for ; Thu, 10 Apr 2014 15:38:07 -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=AL09zUuwDMDFKx2JCPis/gNPiLm8L82MFBuI1gkQdag=; b=CSAtbo4SMb5zD1F+Tk+pI36ozsJ7M8NQL+k6Fp2XLiV8j7FdXCzooid4XP/UlzPUXn AY303TVxeWVr1DiRzs4KyLYEuM13FC/PvscRX48iKNrRPhR1u6TcFTWohJRsx00TuQXj jOPcCvRi64qb5ZBYD2Qy1w/2MBbXcnaJN6Ecc2HZE2943QAbd2UxGGc3VBkdd5b7FDa7 A/wcpjc1QjRGe6V4d/nAOhlkLzHc1gqWDVZ930mFbaj9qOy7D0O3H9FE1ICZn3eCHMV2 eH3VNYI3rfkhGKPmzrZoAegvFwo0SZWkZy+ngzOxXLWyWtY0b7dceOoWPEtiKBwdgiWb kbzQ== MIME-Version: 1.0 X-Received: by 10.43.90.202 with SMTP id bj10mr15394920icc.48.1397169487674; Thu, 10 Apr 2014 15:38:07 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Thu, 10 Apr 2014 15:38:07 -0700 (PDT) In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D082042C6@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D082042C6@nkgeml506-mbx.china.huawei.com> Date: Fri, 11 Apr 2014 00:38:07 +0200 X-Google-Sender-Auth: -309aowZ3NL5nbT7QfF2_uNgQao Message-ID: From: Robert Raszuk To: Lizhenbin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/efdBkh8wXXqIBsE2rrK77102CNo Cc: "aretana@cisco.com" , "spring@ietf.org" Subject: Re: [spring] Comments on Section 2.4//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: Thu, 10 Apr 2014 22:38:15 -0000 Hello Robin, > Regarding the section IPv6 Segment Routing in the Core networks, > I have following comments: > In order to justify the requirement, I think it tries to romove all possible > options for the designed core network: > > -- MPLS: it is definitely be removed firstly. No - no one is suggesting to get rid of MPLS. Please observed that some government networks and obligated by law to run only IPv6. Moreover please also note that new networks architecture *ONLY* assume that core is IPv6 .. example TeraStream Ref: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf > -- L2VPN/L3VPN: it is related with MPLS. I think it is naturally removed. > Then the designed core network has no purpose to bear L2VPN/L3VPN > service. The network is only for IP routing. Completely wrong. L2VPN and L3VPN run fine over pure IP network. You need to distinguish transport from application. MPLS is great demux for applications. However as far as transport I would argue IP is a better choice. As you know MPLS over GRE is widely used today in many environments running MPLS less transport. So your above statement for services is dead wrong. > -- IPv4: it is removed for the reason clarified by the text's self. That is, > there should be no co-existence of IPv4 and IPv6. Or else, the use > cases described for segment routing can only apply to IPv6. The > network is only for IPv6 routing. No .. you have got this sentence wrong as well - sorry :( Document first lists number of requirements then says: "IPv4 protocol does not provide such functionalities today and it is not the intent of this document to address the IPv4 scenario, both because this may create a lot of backward compatibility issues with currently deployed networks and for the security issues that may raise." It does not say that IPv4 should be removed nor it says that there should be no co-existance of IPv4 and IPv6. > -- Multicast: Segment routing cannot cover the use case. The multicast > service should be removed. Then network is only for IPv6 unicast routing. As mentioned already there are few other protocols today other then mLDP and p2mp & mp2mp RSVP-TE to handle multicast quite well. That includes controlled tree constructions via different network topologies. Those tools are widely known and used so claim that multicast service should be removed is dead wrong again. No one claims that. > Then I do not think the debates on the draft should not be simply > blamed on the choice between IPv6 or MPLS. I wonder how many > operators perfers the designed core network for IPv6 segment > routing and whether it is necessary to introduce complex IPv6 > segment routing fowarding for the limited scenarios. I would recommend to allow actual operators to make the design choice for their networks rather then allow vendors to decide for them. Please notice that main editors of this document are actually folks running networks so even if one would like to have an inter-operable solution it should be more then sufficient for this WG to work on it. Best regards, R. From nobody Fri Apr 11 07:28:59 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 E9A5D1A06C8 for ; Fri, 11 Apr 2014 07:28:57 -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 rLp0zMFFIOhi for ; Fri, 11 Apr 2014 07:28:56 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9F51A06A1 for ; Fri, 11 Apr 2014 07:28:55 -0700 (PDT) Received: from mail208-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Apr 2014 14:28:28 +0000 Received: from mail208-ch1 (localhost [127.0.0.1]) by mail208-ch1-R.bigfish.com (Postfix) with ESMTP id C0A4740078D; Fri, 11 Apr 2014 14:28:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail208-ch1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail208-ch1 (localhost.localdomain [127.0.0.1]) by mail208-ch1 (MessageSwitch) id 1397226506208055_17958; Fri, 11 Apr 2014 14:28:26 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail208-ch1.bigfish.com (Postfix) with ESMTP id 2C254300061; Fri, 11 Apr 2014 14:28:26 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Apr 2014 14:28:16 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Apr 2014 07:28:42 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s3BESQV22200; Fri, 11 Apr 2014 07:28:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404111428.s3BESQV22200@magenta.juniper.net> To: "Stefano Previdi (sprevidi)" In-Reply-To: <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> X-MH-In-Reply-To: "Stefano Previdi (sprevidi)" message dated "Wed, 26 Mar 2014 17:59:46 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55166.1397226506.1@juniper.net> Date: Fri, 11 Apr 2014 07:28:26 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/CIMvsAT3XhqgNdQInjiwl7Y2hyM Cc: "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, 11 Apr 2014 14:28:58 -0000 Stefano, > Hi Yakov, > > thanks for your comments. See below. in-line below... [clipped...] > > To reach the > > same scale, an operator would need to introduce additional > > complexity, such as mechanisms described in > > [I-D.ietf-mpls-seamless-mpls] > > > > Perhaps before claiming "additional complexity" in > > [I-D.ietf-mpls-seamless-mpls] the authors of the draft should > > count the number of times the word "simple" or "simplicity" > > occurs in [I-D.ietf-mpls-seamless-mpls] (which btw has one > > of its authors the same as one of the authors of > > draft-martin-spring-segment-routing-ipv6-use-cases). > > a co-author on both drafts is a good thing as it demonstrate > we have different solutions for different (dataplanes) use cases > and this doesn't mean one prevails over the other. > > I don't find anything wrong with this. The above still does not explain what exactly are the mechanisms that "introduce additional complexity" in [I-D.ietf-mpls-seamless-mpls], and how SPRING is going to make the overall solution simpler than [I-D.ietf-mpls-seamless-mpls]. Moreover, if all you want is to "demonstrate we have different solutions for different (dataplanes) use cases, and this doesn't mean one prevails over the other", then the discussion about the "additional complexity" is clearly outside the scope of the use cases document. Yakov. From nobody Fri Apr 11 08:15: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 7F5431A0270 for ; Fri, 11 Apr 2014 08:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 JnaoA8waM1-u for ; Fri, 11 Apr 2014 08:15:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AA4121A029F for ; Fri, 11 Apr 2014 08:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1846; q=dns/txt; s=iport; t=1397229323; x=1398438923; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=amAXuh7WxWlhv3ekGHcjItkbjx9vuwmpyQ7bswVvO+U=; b=j9d4aHigyrA2mN4j2+5jKLS+xGH/jtu0a21qPoGjemmcyh1V83M8j/AQ HrwQbpyFFts0Rtamo6+pWkmjdDSWlWVJ37M3jsOKhV7gjAVn56wQArZwG K4qm8NKwGGkKtJBT93uVpbUKwYRIafPDvpibbPOX6bd9w04RExHeYkW+m w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANcFSFOtJA2H/2dsb2JhbABZgwaBEsROgRsWdIIlAQEBAwEdHT8FCwIBCBgeEDIlAgQOIIdZCMxYF45sB4MkgRQBA5hgkkKBcoE/gis X-IronPort-AV: E=Sophos;i="4.97,842,1389744000"; d="scan'208";a="313982941" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 11 Apr 2014 15:15:23 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3BFFMPV006904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 15:15:23 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 10:15:22 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases Thread-Index: AQHPVZJeCF/rAIooV0WSO2P/LCfCfZsM2mCA Date: Fri, 11 Apr 2014 15:15:21 +0000 Message-ID: References: <201403261739.s2QHd5V66734@magenta.juniper.net> <9C7637CE-C51C-49FA-BAFD-DB30C732B31D@cisco.com> <201404111428.s3BESQV22200@magenta.juniper.net> In-Reply-To: <201404111428.s3BESQV22200@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.211.202] 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/JqkrIfukGxReInq-vdGc32A7NSc Cc: "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, 11 Apr 2014 15:15:32 -0000 On Apr 11, 2014, at 4:28 PM, Yakov Rekhter wrote: > Stefano, >=20 >> Hi Yakov, >>=20 >> thanks for your comments. See below. >=20 > in-line below... >=20 > [clipped...] >=20 >>> To reach the >>> same scale, an operator would need to introduce additional >>> complexity, such as mechanisms described in >>> [I-D.ietf-mpls-seamless-mpls] >>>=20 >>> Perhaps before claiming "additional complexity" in=20 >>> [I-D.ietf-mpls-seamless-mpls] the authors of the draft should >>> count the number of times the word "simple" or "simplicity" >>> occurs in [I-D.ietf-mpls-seamless-mpls] (which btw has one >>> of its authors the same as one of the authors of=20 >>> draft-martin-spring-segment-routing-ipv6-use-cases). >>=20 >> a co-author on both drafts is a good thing as it demonstrate=20 >> we have different solutions for different (dataplanes) use cases=20 >> and this doesn't mean one prevails over the other. >>=20 >> I don't find anything wrong with this. >=20 > The above still does not explain what exactly are the mechanisms that > "introduce additional complexity" in [I-D.ietf-mpls-seamless-mpls], > and how SPRING is going to make the overall solution simpler than > [I-D.ietf-mpls-seamless-mpls]. >=20 > Moreover, if all you want is to "demonstrate we have different > solutions for different (dataplanes) use cases, and this doesn't > mean one prevails over the other", then the discussion about > the "additional complexity" is clearly outside the scope of > the use cases document. the authors want to demonstrate how TE is deployed today and what=20 SR must support and address with the removal of intermediate state=20 maintenance (i.e.: simplification), other than the usual igp state. s. >=20 > Yakov. >=20 From nobody Sat Apr 12 00:13:50 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 EB75E1A03EA for ; Sat, 12 Apr 2014 00:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 z7gTPYLhcbaL for ; Sat, 12 Apr 2014 00:13:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6161C1A0115 for ; Sat, 12 Apr 2014 00:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2051; q=dns/txt; s=iport; t=1397286823; x=1398496423; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=PNLGVo5Zg/F55dg7wpCiHwEPClTcYADtxLjD8ZdZiMg=; b=mN/sw1DPCu3te5zMLnwg1vITSyK8dSv/uGpYSrP/VNx4cSPlGExzem6F a1F76QhMXGTsMHJ7YMniNXy5KvUBh+5weuzGXU+/pAUnJL6FuJln39SrJ 1KJgkcog/7zXot/g/KJEsRb4yCn00u+NvrH0YLe2tHyjp200BIMjc9xuo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAAjnSFOtJV2d/2dsb2JhbABZgwY7V8MqgRgWdIIlAQEBAwE6PQcLAgEZAwECHxAyGwIIAgQTCYdrCA3LZReOe4MegRQEmGGBNpENgXKBP4Ir X-IronPort-AV: E=Sophos;i="4.97,847,1389744000"; d="scan'208";a="317216727" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 12 Apr 2014 07:13:42 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3C7Dfme005998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 12 Apr 2014 07:13:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Sat, 12 Apr 2014 02:13:41 -0500 From: "Stefano Previdi (sprevidi)" To: " ietf.org" Thread-Topic: New Version Notification for draft-ietf-isis-segment-routing-extensions-00.txt Thread-Index: AQHPVhgITnrHrpTyC0m3Y0crhALj7A== Date: Sat, 12 Apr 2014 07:13:40 +0000 Message-ID: <0B78677A-8C78-45D7-A7E3-60572B410ADF@cisco.com> References: <20140412062540.24478.52914.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.196.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B8EBEE90B2A984D84D937750D96BB5B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/MaxF0PHokV1Bxq5KDZJ7jhv74xw Subject: [spring] Fwd: New Version Notification for draft-ietf-isis-segment-routing-extensions-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, 12 Apr 2014 07:13:47 -0000 FYI Thanks. s. Begin forwarded message: > From: > Subject: New Version Notification for draft-ietf-isis-segment-routing-ext= ensions-00.txt > Date: April 12, 2014 8:25:40 AM GMT+02:00 > To: Stefano Previdi , Ahmed Bashandy , Jeff Tantsura , Jeff Tantsura , Hannes Gredler , "Stephane Litkowski= " , Clarence Filsfils , = Stefano Previdi , Clarence Filsfils , Ahmed Bashandy , Hannes Gredler = , Stephane Litkowski >=20 >=20 > A new version of I-D, draft-ietf-isis-segment-routing-extensions-00.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-ietf-isis-segment-routing-extensions > Revision: 00 > Title: IS-IS Extensions for Segment Routing > Document date: 2014-04-11 > Group: isis > Pages: 30 > URL: http://www.ietf.org/internet-drafts/draft-ietf-isis-segme= nt-routing-extensions-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-isis-segment-= routing-extensions/ > Htmlized: http://tools.ietf.org/html/draft-ietf-isis-segment-routin= g-extensions-00 >=20 >=20 > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS and OSPF). >=20 > This draft describes the necessary IS-IS extensions that need to be > introduced for Segment Routing. >=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 Apr 14 06:28:57 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 CB1151A0464 for ; Mon, 14 Apr 2014 06:28:55 -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 lpcSxC8slDl6 for ; Mon, 14 Apr 2014 06:28:51 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 629271A0104 for ; Mon, 14 Apr 2014 06:28:51 -0700 (PDT) Received: from mail219-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Apr 2014 13:28:13 +0000 Received: from mail219-ch1 (localhost [127.0.0.1]) by mail219-ch1-R.bigfish.com (Postfix) with ESMTP id 8FA5F20012D for ; Mon, 14 Apr 2014 13:28:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz936eIzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail219-ch1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail219-ch1 (localhost.localdomain [127.0.0.1]) by mail219-ch1 (MessageSwitch) id 1397482091164686_16500; Mon, 14 Apr 2014 13:28:11 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail219-ch1.bigfish.com (Postfix) with ESMTP id 246E61A0068 for ; Mon, 14 Apr 2014 13:28:11 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Apr 2014 13:28:05 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Apr 2014 06:28:39 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s3EDScV01126 for ; Mon, 14 Apr 2014 06:28:38 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404141328.s3EDScV01126@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13494.1397482118.1@juniper.net> Date: Mon, 14 Apr 2014 06:28:38 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/y0cmpqBybMIVQEABC66jZJ95uts Subject: [spring] New Version Notification for draft-gredler-spring-mpls-03.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, 14 Apr 2014 13:28:55 -0000 fyi and comments ------- Forwarded Message Date: Mon, 14 Apr 2014 06:20:25 -0700 From: To: Sriganesh Kini , Sriganesh Kini , Hannes Gredler , "Luay Jalil" , Yakov Rekhter , "Yakov Rekhter" , Hannes Gredler , Luay Jalil Subject: New Version Notification for draft-gredler-spring-mpls-03.txt A new version of I-D, draft-gredler-spring-mpls-03.txt has been successfully submitted by Yakov Rekhter and posted to the IETF repository. Name: draft-gredler-spring-mpls Revision: 03 Title: Supporting Source/Explicitly Routed Tunnels via Stacked LSPs Document date: 2014-04-14 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-gredler-spring-mpls-0 3.txt Status: https://datatracker.ietf.org/doc/draft-gredler-spring-mpls/ Htmlized: http://tools.ietf.org/html/draft-gredler-spring-mpls-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-gredler-spring-mpls-03 Abstract: This document describes how source/explicitly routed tunnels could be realized using stacked Label Switched Paths (LSPs). This document also describes how use of IS-IS/OSPF as a label distribution protocol fits into the MPLS architecture. 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. The IETF Secretariat ------- End of Forwarded Message From nobody Fri Apr 18 02:00: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 BE2461A00CD; Fri, 18 Apr 2014 02:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 1YKKh8mINA83; Fri, 18 Apr 2014 02:00:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B31A001B; Fri, 18 Apr 2014 02:00:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDG14192; Fri, 18 Apr 2014 09:00:37 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 09:58:55 +0100 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; Fri, 18 Apr 2014 10:00:36 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 18 Apr 2014 17:00:28 +0800 From: Xuxiaohu To: "sfc@ietf.org" Thread-Topic: Why Transport Dependence is deemed as a problem?//re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTBvmFbElTWEybzBPXXbCPGZsVEbjw Date: Fri, 18 Apr 2014 09:00:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> In-Reply-To: <20140416191749.26793.70486.idtracker@ietfa.amsl.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/HPl3TWcMiEgtn3aadFVwm-EtAt8 Cc: "spring@ietf.org" Subject: [spring] Why Transport Dependence is deemed as a problem?//re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.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, 18 Apr 2014 09:00:45 -0000 SGkgYWxsLA0KDQpJdCBzYWlkIGluIHNlY3Rpb24gMi42LiAgVHJhbnNwb3J0IERlcGVuZGVuY2Ug b2YgdGhlIFBTIGRyYWZ0Og0KDQogICJTZXJ2aWNlIGZ1bmN0aW9ucyBjYW4gYW5kIHdpbGwgYmUg ZGVwbG95ZWQgaW4gbmV0d29ya3Mgd2l0aCBhIHJhbmdlDQogICBvZiB0cmFuc3BvcnRzLCBpbmNs dWRpbmcgdW5kZXIgYW5kIG92ZXJsYXlzLiAgVGhlIGNvdXBsaW5nIG9mIHNlcnZpY2UNCiAgIGZ1 bmN0aW9ucyB0byB0b3BvbG9neSByZXF1aXJlcyBzZXJ2aWNlIGZ1bmN0aW9ucyB0byBzdXBwb3J0 IG1hbnkNCiAgIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9ucyBvciBmb3IgYSB0cmFuc3BvcnQgZ2F0 ZXdheSBmdW5jdGlvbiB0byBiZQ0KICAgcHJlc2VudC4iDQoNCkFzc3VtZSB0aGUgZnVuY3Rpb24g b2Ygc2VydmljZSBjaGFpbiBjYW4gYmUgZGl2aWRlZCBpbnRvIHR3byBsYXllcnM6IG9uZSBpcyB0 aGUgc2VydmljZSBwYXRoIGxheWVyIHdoaWNoIGlzIHJlc3BvbnNpYmxlIGZvciBzdGVlcmluZyB0 aGUgcGFja2V0cyBhbG9uZyB0aGUgc2VydmljZSBwYXRoLCB0aGUgb3RoZXIgaXMgdGhlIHNlcnZp Y2UgZnVuY3Rpb24gbGF5ZXIgd2hpY2ggaXMgcmVzcG9uc2libGUgZm9yIGFwcGx5aW5nIGEgZ2l2 ZW4gc2VydmljZSB0byB0aGUgcGFja2V0LiBJIGFncmVlIHRoYXQgdHJhbnNwb3J0IGRlcGVuZGVu Y2UgaXMgYmFkIGZvciB0aGUgc2VydmljZSBmdW5jdGlvbiBsYXllci4gSG93ZXZlciwgSSBkb24n dCB1bmRlcnN0YW5kIHdoeSB0cmFuc3BvcnQgZGVwZW5kZW5jZSBpcyBhbHNvIGJhZCBmb3IgdGhl IHNlcnZpY2UgcGF0aCBsYXllci4gSW4gZmFjdCwgdGhlcmUgYXJlIG9ubHkgdHdvIHVuZGVybGF5 IHRyYW5zcG9ydHMgKGkuZS4sIElQIGFuZCBNUExTKSB3aGljaCBuZWVkIHRvIGJlIGNvbnNpZGVy ZWQgZm9yIHNlcnZpY2UgY2hhaW4uIFRoZXJlZm9yZSwgd2UganVzdCBuZWVkIHRvIGxldmVyYWdl IHRoZSBzb3VyY2Ugcm91dGluZyBjYXBhYmlsaXR5IGFzc29jaWF0ZWQgd2l0aCBJUCBvciBNUExT IHRvIHJlYWxpemUgdGhlIGZ1bmN0aW9uIG9mIHRoZSBzZXJ2aWNlIHBhdGggbGF5ZXIuIFRoYXQn cyB0byBzYXksIHdlIGNhbiB1c2UgYW4gb3JkZXJlZCBsaXN0IG9mIElQIGFkZHJlc3NlcyBvciBN UExTIGxhYmVscyBjYXJyaWVkIGluIHRoZSBwYWNrZXQgdG8gcmVwcmVzZW50IHRoZSBzZXJ2aWNl IHBhdGguIEEgTVBMUyBsYWJlbCBpbiB0aGUgb3JkZXJlZCBsaXN0IG9mIE1QTFMgbGFiZWxzIChp LmUuLCBhIE1QTFMgbGFiZWwgc3RhY2spIG9yIGFuIElQIGFkZHJlc3MgaW4gdGhlIG9yZGVyZWQg bGlzdCBvZiBJUCBhZGRyZXNzZXMgY2FuIGJlIHVzZWQgdG8gaW5kaWNhdGUgZWl0aGVyIGEgc2Vy dmljZSBub2RlIHdpdGhpbiB0aGUgc2VydmljZSBwYXRoIG9yIGEgc2VydmljZSBmdW5jdGlvbiBv biBhIGdpdmVuIHNlcnZpY2Ugbm9kZS4gTm90ZSB0aGF0IE1QTFMgbGFiZWxzIGFuZCBJUCBhZGRy ZXNzZXMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSB1c2VkIGZvciBpbmRpY2F0aW5nIHNlcnZpY2Vz IChlLmcuLCBWUE4gbGFiZWxzIGFuZCBtdWx0aWNhc3QgYWRkcmVzc2VzIGluIHRoZSByYW5nZSBv ZiAyMjQuMC4wLnggb3IgRkYwMjo6eCApLiANCg0KT2YgY291cnNlLCBpZiB5b3Ugc3RpbGwgdGhp bmsgdGhlcmUgYXJlIHRvbyBtdWNoIHdvcmsgdG8gZG8sIHlvdSBjb3VsZCBhY3R1YWxseSBvbmx5 IGNvbnNpZGVyIHRoZSBNUExTLWJhc2VkIGFwcHJvYWNoIChpLmUuLCB1c2luZyBhIE1QTFMgbGFi ZWwgc3RhY2sgdG8gcmVwcmVzZW50IGEgc2VydmljZSBwYXRoKSBzaW5jZSBpdCBjb3VsZCBhbHNv IGJlIGFwcGxpY2FibGUgaW4gYm90aCBJUHY0IGFuZCBJUHY2IG5ldHdvcmtzIHdpdGggdGhlIGhl bHAgb2YgYW55IGtpbmQgb2YgTVBMUyBvdmVyIElQIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9naWVz LiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcNCj4gt6LLzcqxvOQ6IDIwMTTE6jTUwjE3yNUgMzoxOA0KPiDK1bz+yMs6 IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiCzrcvNOiBzZmNAaWV0Zi5vcmcNCj4g1vfM4jogW3Nm Y10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+ IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBXb3JraW5nIEdyb3VwIG9mIHRo ZQ0KPiBJRVRGLg0KPiANCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluaW5nIFByb2JsZW0gU3RhdGVtZW50DQo+ICAgICAgICAgQXV0aG9ycyAgICAgICAg IDogUGF1bCBRdWlubg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRob21hcyBOYWRlYXUN Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0 LnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTgNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTQt MDQtMTYNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIG92 ZXJ2aWV3IG9mIHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiAgICBkZXBsb3ltZW50 IG9mIHNlcnZpY2UgZnVuY3Rpb25zIChzdWNoIGFzIGZpcmV3YWxscywgbG9hZCBiYWxhbmNlcnMp DQo+ICAgIGluIGxhcmdlLXNjYWxlIGVudmlyb25tZW50cy4gIFRoZSB0ZXJtIHNlcnZpY2UgZnVu Y3Rpb24gY2hhaW5pbmcgaXMNCj4gICAgdXNlZCB0byBkZXNjcmliZSB0aGUgZGVmaW5pdGlvbiBh bmQgaW5zdGFudGlhdGlvbiBvZiBhbiBvcmRlcmVkIHNldA0KPiAgICBvZiBpbnN0YW5jZXMgb2Yg c3VjaCBzZXJ2aWNlIGZ1bmN0aW9ucywgYW5kIHRoZSBzdWJzZXF1ZW50ICJzdGVlcmluZyINCj4g ICAgb2YgdHJhZmZpYyBmbG93cyB0aHJvdWdoIHRob3NlIHNlcnZpY2UgZnVuY3Rpb25zLg0KPiAN Cj4gICAgVGhlIHNldCBvZiBlbmFibGVkIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5zIHJlZmxlY3Qg b3BlcmF0b3Igc2VydmljZQ0KPiAgICBvZmZlcmluZ3MgYW5kIGlzIGRlc2lnbmVkIGluIGNvbmp1 bmN0aW9uIHdpdGggYXBwbGljYXRpb24gZGVsaXZlcnkNCj4gICAgYW5kIHNlcnZpY2UgYW5kIG5l dHdvcmsgcG9saWN5Lg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC8NCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNA0KPiANCj4gQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNA0KPiAN Cj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Fri Apr 18 04:32: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 2F12D1A01C4; Fri, 18 Apr 2014 04:32:22 -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 p6xkaq9VY43d; Fri, 18 Apr 2014 04:32:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D6E1A00ED; Fri, 18 Apr 2014 04:32:16 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418113215.30486.23671.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 04:32:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/90e58e06B4OUbWa40LmtsoUqc9M Cc: spring@ietf.org Subject: [spring] I-D Action: draft-previdi-spring-problem-statement-03.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: Fri, 18 Apr 2014 11:32:22 -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-previdi-spring-problem-statement-03.txt Pages : 18 Date : 2014-04-18 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-previdi-spring-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-previdi-spring-problem-statement-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-previdi-spring-problem-statement-03 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 Apr 18 04:46:01 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 115781A01BB for ; Fri, 18 Apr 2014 04:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 Ol21H-ksDjld for ; Fri, 18 Apr 2014 04:45:58 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 50B9C1A017A for ; Fri, 18 Apr 2014 04:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2743; q=dns/txt; s=iport; t=1397821554; x=1399031154; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=WQZpzkUThY16g9CgjtdRAxVpr3kiXPa+2vLVkSBiK94=; b=G7slOuiSDJ0iygiCYj6HNmsWx9iM6oeGJt7sjpW2FQpHHuoP9aBkrcgM crcIWIm3NqXpb6kUjhWqQxq6a4dalNUMxufwbW9cg0Z8AFBKOkl9q3OOe Vl0hZxXzUFlYnH5RBK0wdHQSYRQAZIkymn0nxroUCUCqotV2mvdXJ9IYs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFABwPUVOtJV2a/2dsb2JhbABagwZPUQa8M4c8gRwWdIIlAQEBAwEBAQE3NBALAgEZAQIBAh8QJwsUAwQCCAIEEwmIMAgIBcxAF45kC4IodoEUBJhugTeLSoVOgzGCKw X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="36902066" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 18 Apr 2014 11:45:54 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3IBjsZj007532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Apr 2014 11:45:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 06:45:54 -0500 From: "Stefano Previdi (sprevidi)" To: " ietf.org" Thread-Topic: I-D Action: draft-filsfils-spring-segment-routing-mpls-01.txt Thread-Index: AQHPWvvALwKz9WGEyEeE8vcgWetCUg== Date: Fri, 18 Apr 2014 11:45:53 +0000 Message-ID: <2CEC5F88-DF29-4D7C-ACE4-9678E296C3A1@cisco.com> References: <20140418114133.7640.51388.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.162.88] Content-Type: text/plain; charset="us-ascii" Content-ID: <2EDF4089A130CD4F87549D72032F596C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/FIf5GdkcsC3clNLJPpFSNFFwlB0 Subject: [spring] Fwd: I-D Action: draft-filsfils-spring-segment-routing-mpls-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: Fri, 18 Apr 2014 11:46:00 -0000 FYI s. Begin forwarded message: > From: > Subject: I-D Action: draft-filsfils-spring-segment-routing-mpls-01.txt > Date: April 18, 2014 1:41:33 PM GMT+02:00 > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Segment Routing with MPLS data plane > Authors : Clarence Filsfils > Stefano Previdi > Ahmed Bashandy > Bruno Decraene > Stephane Litkowski > Martin Horneffer > Igor Milojevic > Rob Shakir > Saku Ytti > Wim Henderickx > Jeff Tantsura > Edward Crabbe > Filename : draft-filsfils-spring-segment-routing-mpls-01.txt > Pages : 12 > Date : 2014-04-18 >=20 > Abstract: > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through a controlled set of instructions, called > segments, by prepending the packet with an SR header. A segment can > represent any instruction, topological or service-based. SR allows > to enforce a flow through any topological path and service chain > while maintaining per-flow state only at the ingress node to the SR > domain. >=20 > Segment Routing can be directly applied to the MPLS architecture with > no change in the forwarding plane. This drafts describes how Segment > Routing operates on top of the MPLS data plane. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-mp= ls/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-filsfils-spring-segment-routing-= mpls-01 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Apr 18 04:46: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 AA5E41A01BB for ; Fri, 18 Apr 2014 04:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 HSzG3fd98XEc for ; Fri, 18 Apr 2014 04:46:01 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id B06F11A01D9 for ; Fri, 18 Apr 2014 04:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2844; q=dns/txt; s=iport; t=1397821558; x=1399031158; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=J1giJqsOKUDiQBhymbvWlxOA3gpTAn5ETWPc/k9wYKc=; b=gz8ptMBsyHIXFg1XvPWLtMzwPDDoWuZvm/Xu3DQ1STCxtsxImkVmffWl g6sr0AIT3pP36qWhoGWkvJHFPJZJTPRWvKCNShXjmbtFw4oJv3+TubHZW S+KzK9JVxDQqx3E11ahbLPA1lMRO76HPqbCYswMGRh7cGDFSMUcx9oCDc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFABwPUVOtJV2Y/2dsb2JhbABagwZPV7wzhzyBHBZ0giUBAQEDAQEBATc0EAsCARkBAgECHxAnCxQDBAIIAgQTCYgwCA3MQBeOZAuCKHaBFASYboE3i0qFToMxgis X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="36888647" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 18 Apr 2014 11:45:57 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3IBjvDH001357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Apr 2014 11:45:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 06:45:57 -0500 From: "Stefano Previdi (sprevidi)" To: " ietf.org" Thread-Topic: I-D Action: draft-filsfils-spring-segment-routing-ldp-interop-01.txt Thread-Index: AQHPWvvCWdbGN3o0KUeUSm4mKtznhw== Date: Fri, 18 Apr 2014 11:45:56 +0000 Message-ID: References: <20140418113810.15890.18199.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.162.88] 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/m_vP0fSny9daqgsKQRaj-4pzEh0 Subject: [spring] Fwd: I-D Action: draft-filsfils-spring-segment-routing-ldp-interop-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: Fri, 18 Apr 2014 11:46:03 -0000 FYI. s. Begin forwarded message: > From: > Subject: I-D Action: draft-filsfils-spring-segment-routing-ldp-interop-01= .txt > Date: April 18, 2014 1:38:10 PM GMT+02:00 > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Segment Routing interoperability with LDP > Authors : Clarence Filsfils > Stefano Previdi > Ahmed Bashandy > Bruno Decraene > Stephane Litkowski > Martin Horneffer > Igor Milojevic > Rob Shakir > Saku Ytti > Wim Henderickx > Jeff Tantsura > Edward Crabbe > Filename : draft-filsfils-spring-segment-routing-ldp-interop-01.t= xt > Pages : 16 > Date : 2014-04-18 >=20 > Abstract: > A Segment Routing (SR) node steers a packet through a controlled set > of instructions, called segments, by prepending the packet with an SR > header. A segment can represent any instruction, topological or > service-based. SR allows to enforce a flow through any topological > path and service chain while maintaining per-flow state only at the > ingress node to the SR domain. >=20 > The Segment Routing architecture can be directly applied to the MPLS > data plane with no change in the forwarding plane. This drafts > describes how Segment Routing operates in a network where LDP is > deployed and in the case where SR-capable and non-SR-capable nodes > coexist. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ld= p-interop/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-inte= rop-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-filsfils-spring-segment-routing-= ldp-interop-01 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Apr 18 10:23:30 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 2E2E51A0444 for ; Fri, 18 Apr 2014 10:23:26 -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 hztcZ1GQcBmA for ; Fri, 18 Apr 2014 10:23:23 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 886551A0429 for ; Fri, 18 Apr 2014 10:23:23 -0700 (PDT) Received: from mail16-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Apr 2014 17:22:32 +0000 Received: from mail16-ch1 (localhost [127.0.0.1]) by mail16-ch1-R.bigfish.com (Postfix) with ESMTP id 9CB152005B1; Fri, 18 Apr 2014 17:22:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.10; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz98dI9371I1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: softfail (mail16-ch1: transitioning domain of juniper.net does not designate 66.129.239.10 as permitted sender) client-ip=66.129.239.10; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail16-ch1 (localhost.localdomain [127.0.0.1]) by mail16-ch1 (MessageSwitch) id 1397841749685728_17548; Fri, 18 Apr 2014 17:22:29 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail16-ch1.bigfish.com (Postfix) with ESMTP id A36A44C004F; Fri, 18 Apr 2014 17:22:29 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.239.10) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Apr 2014 17:22:22 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Apr 2014 10:23:08 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s3IHN7V08892; Fri, 18 Apr 2014 10:23:07 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404181723.s3IHN7V08892@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40976.1397841787.1@juniper.net> Date: Fri, 18 Apr 2014 10:23:07 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/spring/cbGEMglZCab-91ErHX3Q0Bf8Fr0 Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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, 18 Apr 2014 17:23:26 -0000 Stefano, > Hi Yakov, > > On Apr 4, 2014, at 10:53 PM, Yakov Rekhter wrote: > > Stefano, > > > >> All, > >> > >> this is the new version of the problem-statement draft incorporating > >> the latest comments. > > > > Section 5.1.1.2 is clearly an improvement over what was in the > > previous version, although some text is still problematic. > > Specifically, "C only installs the path via AS2 in its RIB." If it > > is the Adj-RIB-Out, then C wouldn't be able to advertise the path > > via AS3 inside AS1 (as this path is not in the Adj-RIB-Out). And > > if it is the Loc-RIB, then the Adj-RIB-Out would have only the path > > via AS2 (as the Adj-RIB-Out is populated from the Loc-RIB), and C > > would not be able to advertise the path via AS3 inside AS1. Either > > way, this would contradict the assumption that "C propagates all > > the paths to Z within AS1 (add-path)." > > > I'll address your BGP concerns on a separate thread. The only problem with the text in 5.1.1.2 in the -02 version of the draft is the following sentence "C only installs the path via AS2 in its RIB." To fix to this problem the sentence should say that "C may install in its FIB only the route via AS2, or only the route via AS3, or both." The rest of the text in 5.1.1.2 in the -02 version is ok. Instead, section 5.1.1.2 in the -03 version of the draft contains completely different text, which brings up a whole bunch of new questions. To facilitate timely progress of this document I would suggest to replace the new text in 5.1.1.2 with the text that was there in the -02 version plus the fix I suggested above. Yakov. From nobody Fri Apr 18 10:52:45 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 607761A01D4; Fri, 18 Apr 2014 05:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 AsEfLdjiPY4A; Fri, 18 Apr 2014 05:42:45 -0700 (PDT) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6941A01D9; Fri, 18 Apr 2014 05:42:45 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 05:42:41 -0700 From: Ron Parker To: Xuxiaohu , "sfc@ietf.org" Thread-Topic: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWuSwN6yOCWfBXEiCP5lApG8PzpsXUDbQ Date: Fri, 18 Apr 2014 12:42:40 +0000 Message-ID: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/3eqLOxhHd7JfQxlg44bpJQkzhCU X-Mailman-Approved-At: Fri, 18 Apr 2014 10:52:43 -0700 Cc: "spring@ietf.org" Subject: Re: [spring] [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.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, 18 Apr 2014 12:42:47 -0000 WGlhb2h1LA0KDQpXaGlsZSB0aGUgc3RhY2sgb2YgSVAgYWRkcmVzc2VzIGlzIHNpbXBsZSwgY29u Y2VwdHVhbGx5LCBpdCBpcyBxdWl0ZSBleHBlbnNpdmUgb24gdGhlIHdpcmUsIGVzcGVjaWFsbHkg d2l0aCBJUHY2IGFkZHJlc3Nlcy4gICANCg0KQSBzdGFjayBvZiBNUExTIGxhYmVscyBpcyBhbHNv IGNvbmNlcHR1YWxseSBzaW1wbGUsIGJ1dCB0aGUgdXNlIG9mIE1QTFMgaXMgbm90IHVuaXZlcnNh bCwgZXNwZWNpYWxseSB3aXRoaW4gZGF0YSBjZW50ZXIgZW52aXJvbm1lbnRzLiAgIEFsc28sIHRo aXMgdXNlIG9mIHRoZSBNUExTIGxhYmVscyBpcyBzb21ld2hhdCBkaWZmZXJlbnQsIHNlbWFudGlj YWxseSwgYW5kIGNvdWxkIGNhdXNlIGlzc3VlcyBpZiB1c2VkIGNvbmN1cnJlbnRseSB3aXRoIHRy YWRpdGlvbmFsIE1QTFMgdXNlIGNhc2VzLiAgIEVzcGVjaWFsbHkgZ2l2ZW4gdGhhdCBleGlzdGlu ZyBNUExTIGxhYmVscyBhcmUgZG93bnN0cmVhbSBhbGxvY2F0ZWQgYnV0IFNGQyBpcyBlc3NlbnRp YWxseSBzb3VyY2Ugcm91dGVkLiAgIFBlcmhhcHMgdGhhdCBpc3N1ZSBjb3VsZCBiZSBzb2x2ZWQs IGJ1dCBhdCB0aGUgZXhwZW5zZSBvZiBhIG1vcmUgY29tcGxleCBhbmQgaW52YXNpdmUgY29udHJv bCBwbGFuZS4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUN ClNlbnQ6IEZyaWRheSwgQXByaWwgMTgsIDIwMTQgNTowMCBBTQ0KVG86IHNmY0BpZXRmLm9yZw0K Q2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gV2h5IFRyYW5zcG9ydCBEZXBlbmRl bmNlIGlzIGRlZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1z ZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQoNCkhpIGFsbCwNCg0KSXQgc2FpZCBpbiBzZWN0 aW9uIDIuNi4gIFRyYW5zcG9ydCBEZXBlbmRlbmNlIG9mIHRoZSBQUyBkcmFmdDoNCg0KICAiU2Vy dmljZSBmdW5jdGlvbnMgY2FuIGFuZCB3aWxsIGJlIGRlcGxveWVkIGluIG5ldHdvcmtzIHdpdGgg YSByYW5nZQ0KICAgb2YgdHJhbnNwb3J0cywgaW5jbHVkaW5nIHVuZGVyIGFuZCBvdmVybGF5cy4g IFRoZSBjb3VwbGluZyBvZiBzZXJ2aWNlDQogICBmdW5jdGlvbnMgdG8gdG9wb2xvZ3kgcmVxdWly ZXMgc2VydmljZSBmdW5jdGlvbnMgdG8gc3VwcG9ydCBtYW55DQogICB0cmFuc3BvcnQgZW5jYXBz dWxhdGlvbnMgb3IgZm9yIGEgdHJhbnNwb3J0IGdhdGV3YXkgZnVuY3Rpb24gdG8gYmUNCiAgIHBy ZXNlbnQuIg0KDQpBc3N1bWUgdGhlIGZ1bmN0aW9uIG9mIHNlcnZpY2UgY2hhaW4gY2FuIGJlIGRp dmlkZWQgaW50byB0d28gbGF5ZXJzOiBvbmUgaXMgdGhlIHNlcnZpY2UgcGF0aCBsYXllciB3aGlj aCBpcyByZXNwb25zaWJsZSBmb3Igc3RlZXJpbmcgdGhlIHBhY2tldHMgYWxvbmcgdGhlIHNlcnZp Y2UgcGF0aCwgdGhlIG90aGVyIGlzIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGxheWVyIHdoaWNoIGlz IHJlc3BvbnNpYmxlIGZvciBhcHBseWluZyBhIGdpdmVuIHNlcnZpY2UgdG8gdGhlIHBhY2tldC4g SSBhZ3JlZSB0aGF0IHRyYW5zcG9ydCBkZXBlbmRlbmNlIGlzIGJhZCBmb3IgdGhlIHNlcnZpY2Ug ZnVuY3Rpb24gbGF5ZXIuIEhvd2V2ZXIsIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdHJhbnNwb3J0 IGRlcGVuZGVuY2UgaXMgYWxzbyBiYWQgZm9yIHRoZSBzZXJ2aWNlIHBhdGggbGF5ZXIuIEluIGZh Y3QsIHRoZXJlIGFyZSBvbmx5IHR3byB1bmRlcmxheSB0cmFuc3BvcnRzIChpLmUuLCBJUCBhbmQg TVBMUykgd2hpY2ggbmVlZCB0byBiZSBjb25zaWRlcmVkIGZvciBzZXJ2aWNlIGNoYWluLiBUaGVy ZWZvcmUsIHdlIGp1c3QgbmVlZCB0byBsZXZlcmFnZSB0aGUgc291cmNlIHJvdXRpbmcgY2FwYWJp bGl0eSBhc3NvY2lhdGVkIHdpdGggSVAgb3IgTVBMUyB0byByZWFsaXplIHRoZSBmdW5jdGlvbiBv ZiB0aGUgc2VydmljZSBwYXRoIGxheWVyLiBUaGF0J3MgdG8gc2F5LCB3ZSBjYW4gdXNlIGFuIG9y ZGVyZWQgbGlzdCBvZiBJUCBhZGRyZXNzZXMgb3IgTVBMUyBsYWJlbHMgY2FycmllZCBpbiB0aGUg cGFja2V0IHRvIHJlcHJlc2VudCB0aGUgc2VydmljZSBwYXRoLiBBIE1QTFMgbGFiZWwgaW4gdGhl IG9yZGVyZWQgbGlzdCBvZiBNUExTIGxhYmVscyAoaS5lLiwgYSBNUExTIGxhYmVsIHN0YWNrKSBv ciBhbiBJUCBhZGRyZXNzIGluIHRoZSBvcmRlcmVkIGxpc3Qgb2YgSVAgYWRkcmVzc2VzIGNhbiBi ZSB1c2VkIHRvIGluZGljYXRlIGVpdGhlciBhIHNlcnZpY2Ugbm9kZSB3aXRoaW4gdGhlIHNlcnZp Y2UgcGF0aCBvciBhIHNlcnZpY2UgZnVuY3Rpb24gb24gYSBnaXZlbiBzZXJ2aWNlIG5vZGUuIE5v dGUgdGhhdCBNUExTIGxhYmVscyBhbmQgSVAgYWRkcmVzc2VzIGhhdmUgYmVlbiBzdWNjZXNzZnVs bHkgdXNlZCBmb3IgaW5kaWNhdGluZyBzZXJ2aWNlcyAoZS5nLiwgVlBOIGxhYmVscyBhbmQgbXVs dGljYXN0IGFkZHJlc3NlcyBpbiB0aGUgcmFuZ2Ugb2YgMjI0LjAuMC54IG9yIEZGMDI6OnggKS4g DQoNCk9mIGNvdXJzZSwgaWYgeW91IHN0aWxsIHRoaW5rIHRoZXJlIGFyZSB0b28gbXVjaCB3b3Jr IHRvIGRvLCB5b3UgY291bGQgYWN0dWFsbHkgb25seSBjb25zaWRlciB0aGUgTVBMUy1iYXNlZCBh cHByb2FjaCAoaS5lLiwgdXNpbmcgYSBNUExTIGxhYmVsIHN0YWNrIHRvIHJlcHJlc2VudCBhIHNl cnZpY2UgcGF0aCkgc2luY2UgaXQgY291bGQgYWxzbyBiZSBhcHBsaWNhYmxlIGluIGJvdGggSVB2 NCBhbmQgSVB2NiBuZXR3b3JrcyB3aXRoIHRoZSBoZWxwIG9mIGFueSBraW5kIG9mIE1QTFMgb3Zl ciBJUCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ2llcy4gDQoNCkJlc3QgcmVnYXJkcywNClhpYW9o dQ0KDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ILeiy83Ksbzk OiAyMDE0xOo01MIxN8jVIDM6MTgNCj4gytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4g s63LzTogc2ZjQGlldGYub3JnDQo+INb3zOI6IFtzZmNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt c2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NCj4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlcnZpY2UgRnVuY3Rp b24gQ2hhaW5pbmcgV29ya2luZyANCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAg IFRpdGxlICAgICAgICAgICA6IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgUHJvYmxlbSBTdGF0 ZW1lbnQNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBQYXVsIFF1aW5uDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGhvbWFzIE5hZGVhdQ0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+IAlQYWdlcyAgICAgICAgICAg OiAxOA0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxNC0wNC0xNg0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YgdGhlIGlzc3VlcyBhc3Nv Y2lhdGVkIHdpdGggdGhlDQo+ICAgIGRlcGxveW1lbnQgb2Ygc2VydmljZSBmdW5jdGlvbnMgKHN1 Y2ggYXMgZmlyZXdhbGxzLCBsb2FkIGJhbGFuY2VycykNCj4gICAgaW4gbGFyZ2Utc2NhbGUgZW52 aXJvbm1lbnRzLiAgVGhlIHRlcm0gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcw0KPiAgICB1 c2VkIHRvIGRlc2NyaWJlIHRoZSBkZWZpbml0aW9uIGFuZCBpbnN0YW50aWF0aW9uIG9mIGFuIG9y ZGVyZWQgc2V0DQo+ICAgIG9mIGluc3RhbmNlcyBvZiBzdWNoIHNlcnZpY2UgZnVuY3Rpb25zLCBh bmQgdGhlIHN1YnNlcXVlbnQgInN0ZWVyaW5nIg0KPiAgICBvZiB0cmFmZmljIGZsb3dzIHRocm91 Z2ggdGhvc2Ugc2VydmljZSBmdW5jdGlvbnMuDQo+IA0KPiAgICBUaGUgc2V0IG9mIGVuYWJsZWQg c2VydmljZSBmdW5jdGlvbiBjaGFpbnMgcmVmbGVjdCBvcGVyYXRvciBzZXJ2aWNlDQo+ICAgIG9m ZmVyaW5ncyBhbmQgaXMgZGVzaWduZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhcHBsaWNhdGlvbiBk ZWxpdmVyeQ0KPiAgICBhbmQgc2VydmljZSBhbmQgbmV0d29yayBwb2xpY3kuDQo+IA0KPiANCj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3Rh dGVtZW50Lw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0t c3RhdGVtZW50LTA0DQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0DQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Sun Apr 20 03:13:41 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 99E5D1A007F for ; Sun, 20 Apr 2014 03:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 wAtRBu9I_npI for ; Sun, 20 Apr 2014 03:12:59 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 050961A010D for ; Sun, 20 Apr 2014 03:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2044; q=dns/txt; s=iport; t=1397988773; x=1399198373; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GycZv/Ly8uHE1mwj3GLhdhVq31eBCIBmrjwhULiFscE=; b=Gp93XAXJmw+hJIOHQtrfBFyHdg7hW4IfPMKmADJAT/crlc7/v7YMNr9L G2Nt0mQEpB5ljMg3LBWzAFtK6zGy7vOgmyzYb49ym0unYzysOnDTXMgNb xPt3xFQJErzXSOYNWkc1lAPzjDxYPxN1SNwruDn7cV7kZ+CxNgyhHMl+s s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAIlLU1OtJA2I/2dsb2JhbABYgwaBJsQGgRoWdIIlAQEBAwE6PwULAgEIGB4QMiUCBA6IPgjNEheOYgeEOAEDmG6ST4Mxgis X-IronPort-AV: E=Sophos;i="4.97,891,1389744000"; d="scan'208";a="37250431" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 20 Apr 2014 10:12:53 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3KACr9u017674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Apr 2014 10:12:53 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Sun, 20 Apr 2014 05:12:52 -0500 From: "Stefano Previdi (sprevidi)" To: Yakov Rekhter Thread-Topic: [spring] I-D Action: draft-previdi-spring-problem-statement-02.txt Thread-Index: AQHPWyrklUQnBJWCSE6C5gBo29SeTpsan6sA Date: Sun, 20 Apr 2014 10:12:52 +0000 Message-ID: References: <201404181723.s3IHN7V08892@magenta.juniper.net> In-Reply-To: <201404181723.s3IHN7V08892@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <03C2F0D8AB099840A5E1FD355BE90A2A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/MnVClGcHStYntUuKuGly5kEMgak Cc: "" Subject: Re: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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: Sun, 20 Apr 2014 10:13:05 -0000 Hi Yakov, On Apr 18, 2014, at 7:23 PM, Yakov Rekhter wrote: > Stefano, >=20 >> Hi Yakov, >>=20 >> On Apr 4, 2014, at 10:53 PM, Yakov Rekhter wrote: >>> Stefano, >>>=20 >>>> All, >>>>=20 >>>> this is the new version of the problem-statement draft incorporating=20 >>>> the latest comments. >>>=20 >>> Section 5.1.1.2 is clearly an improvement over what was in the >>> previous version, although some text is still problematic. >>> Specifically, "C only installs the path via AS2 in its RIB." If it >>> is the Adj-RIB-Out, then C wouldn't be able to advertise the path >>> via AS3 inside AS1 (as this path is not in the Adj-RIB-Out). And >>> if it is the Loc-RIB, then the Adj-RIB-Out would have only the path >>> via AS2 (as the Adj-RIB-Out is populated from the Loc-RIB), and C >>> would not be able to advertise the path via AS3 inside AS1. Either >>> way, this would contradict the assumption that "C propagates all >>> the paths to Z within AS1 (add-path)." >>=20 >>=20 >> I'll address your BGP concerns on a separate thread. >=20 > The only problem with the text in 5.1.1.2 in the -02 version of the > draft is the following sentence "C only installs the path via AS2 > in its RIB." To fix to this problem the sentence should say that > "C may install in its FIB only the route via AS2, or only the route > via AS3, or both." The rest of the text in 5.1.1.2 in the -02 version > is ok. >=20 > Instead, section 5.1.1.2 in the -03 version of the draft contains > completely different text, which brings up a whole bunch of new > questions. >=20 > To facilitate timely progress of this document I would suggest to > replace the new text in 5.1.1.2 with the text that was there in the > -02 version plus the fix I suggested above. if you feel your concerns were better addressed by the previous=20 text (with your modification), I don't mind put it back so to=20 make progress with the draft. I'll re-spin the draft tomorrow. Happy Easter. Thanks. s. > Yakov. >=20 From nobody Sun Apr 20 14:28:59 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 CE47B1A003B for ; Sun, 20 Apr 2014 14:28:57 -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 ZUDsTcMjXYGR for ; Sun, 20 Apr 2014 14:28:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id A50291A0039 for ; Sun, 20 Apr 2014 14:28:55 -0700 (PDT) Received: from DM2PR05CA021.namprd05.prod.outlook.com (10.141.241.11) by BY2PR05MB111.namprd05.prod.outlook.com (10.242.38.26) with Microsoft SMTP Server (TLS) id 15.0.921.12; Sun, 20 Apr 2014 21:28:43 +0000 Received: from BY2FFO11FD027.protection.gbl (2a01:111:f400:7c0c::177) by DM2PR05CA021.outlook.office365.com (2a01:111:e400:2464::11) with Microsoft SMTP Server (TLS) id 15.0.921.12 via Frontend Transport; Sun, 20 Apr 2014 21:28:42 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Sun, 20 Apr 2014 21:28:42 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 20 Apr 2014 14:28:41 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s3KLSfV91390; Sun, 20 Apr 2014 14:28:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404202128.s3KLSfV91390@magenta.juniper.net> To: "Stefano Previdi (sprevidi)" In-Reply-To: References: <201404181723.s3IHN7V08892@magenta.juniper.net> X-MH-In-Reply-To: "Stefano Previdi (sprevidi)" message dated "Sun, 20 Apr 2014 10:12:52 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73130.1398029320.1@juniper.net> Date: Sun, 20 Apr 2014 14:28:40 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(458001)(199002)(189002)(51704005)(83072002)(85852003)(76482001)(99396002)(46102001)(74502001)(4396001)(87936001)(20776003)(92726001)(76176999)(50986999)(77982001)(97756001)(81542001)(54356999)(77096999)(97736001)(2009001)(6806004)(47776003)(44976005)(80022001)(83322001)(92566001)(81342001)(84676001)(74662001)(31966008)(16796002)(50466002)(86362001)(23726002)(80976001)(46406003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB111; H:P-EMF01-SAC.jnpr.net; FPR:ECBEF2AC.AFF21529.A1DB53BB.46EDFAC1.20275; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Forefront-PRVS: 0187F3EA14 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/C9c0FmGOusyck11eeSMWVJ-RIJc Cc: "" Subject: Re: [spring] I-D Action: draft-previdi-spring-problem-statement-02.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: Sun, 20 Apr 2014 21:28:58 -0000 Stefano, > >>>> this is the new version of the problem-statement draft incorporating > >>>> the latest comments. > >>> > >>> Section 5.1.1.2 is clearly an improvement over what was in the > >>> previous version, although some text is still problematic. > >>> Specifically, "C only installs the path via AS2 in its RIB." If it > >>> is the Adj-RIB-Out, then C wouldn't be able to advertise the path > >>> via AS3 inside AS1 (as this path is not in the Adj-RIB-Out). And > >>> if it is the Loc-RIB, then the Adj-RIB-Out would have only the path > >>> via AS2 (as the Adj-RIB-Out is populated from the Loc-RIB), and C > >>> would not be able to advertise the path via AS3 inside AS1. Either > >>> way, this would contradict the assumption that "C propagates all > >>> the paths to Z within AS1 (add-path)." > >> > >> > >> I'll address your BGP concerns on a separate thread. > > > > The only problem with the text in 5.1.1.2 in the -02 version of the > > draft is the following sentence "C only installs the path via AS2 > > in its RIB." To fix to this problem the sentence should say that > > "C may install in its FIB only the route via AS2, or only the route > > via AS3, or both." The rest of the text in 5.1.1.2 in the -02 version > > is ok. > > > > Instead, section 5.1.1.2 in the -03 version of the draft contains > > completely different text, which brings up a whole bunch of new > > questions. > > > > To facilitate timely progress of this document I would suggest to > > replace the new text in 5.1.1.2 with the text that was there in the > > -02 version plus the fix I suggested above. > > if you feel your concerns were better addressed by the previous > text (with your modification), I don't mind put it back so to > make progress with the draft. I'll re-spin the draft tomorrow. That would be good. Thanks ! Yakov. From nobody Sun Apr 20 14:43:44 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 82A661A0051 for ; Sun, 20 Apr 2014 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 Wb7UZpq-r45z for ; Sun, 20 Apr 2014 14:43:35 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 66E281A004B for ; Sun, 20 Apr 2014 14:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=313; q=dns/txt; s=iport; t=1398030211; x=1399239811; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=E22pc6vwUi3QV1XIe6u4tUMxtqtl8ewHyHOi6dTmrIk=; b=eNaoaLn0TFWQ+UdsU9N68Fyyltm2hlzb37CdSVWZqHpf3NAZA5cp2PY/ iME0tgTzpQ/vWfkcwcJBlHrHyYh+oQR3VOssydBZsL5W/bVujP4YrqLQF ouqf4nUyTsvfnGed4265vd4c4X7Qy4vbEEVVg6Tcux40ey8ARmN+fUcCu c=; X-IronPort-AV: E=Sophos;i="4.97,894,1389744000"; d="scan'208";a="17414448" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 20 Apr 2014 21:43:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3KLhTfq024537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Apr 2014 21:43:29 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s3KLhQwE029387; Sun, 20 Apr 2014 22:43:26 +0100 (BST) Message-ID: <53543F84.4090700@cisco.com> Date: Sun, 20 Apr 2014 22:43:32 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Robert Raszuk , Lizhenbin References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D082042C6@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/spring/1EAnSxh3V-1dQ2iesG9U1OLR2LI Cc: "aretana@cisco.com" , "spring@ietf.org" Subject: Re: [spring] Comments on Section 2.4//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 Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 21:43:40 -0000 On 10/04/2014 23:38, Robert Raszuk wrote: > Please observed that some government networks and obligated by law to > run only IPv6. That remark reminds be of the government directive that all departments would run the Government OSI Protocol and communications with government would use same. Stewart From nobody Mon Apr 21 01:27: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 126E41A0189; Mon, 21 Apr 2014 01:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 sgjRMG1aOjjh; Mon, 21 Apr 2014 01:27:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 128071A01BD; Mon, 21 Apr 2014 01:26:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFW81279; Mon, 21 Apr 2014 08:26:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 09:26:00 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 09:26:48 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 16:26:44 +0800 From: Xuxiaohu To: Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWwO2ZN9DNYdRwEi3MZ5fyWQNNpsbucIA Date: Mon, 21 Apr 2014 08:26:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/fZOEBwOVt-1-RK_MsmAXbx5eGVc Cc: "spring@ietf.org" Subject: Re: [spring] [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.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, 21 Apr 2014 08:27:05 -0000 SGkgUm9uLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVzcG9u c2UgaW5saW5lLg0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbiBQYXJrZXINCj4gt6LLzcqxvOQ6IDIwMTTE 6jTUwjE4yNUgMjA6NDMNCj4gytW8/sjLOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnDQo+ILOty806 IHNwcmluZ0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW3NmY10gV2h5IFRyYW5zcG9ydCBEZXBlbmRl bmNlIGlzIGRlZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EDQo+IEFjdGlvbjogZHJhZnQtaWV0 Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+IA0KPiBYaWFvaHUsDQo+IA0KPiBXaGls ZSB0aGUgc3RhY2sgb2YgSVAgYWRkcmVzc2VzIGlzIHNpbXBsZSwgY29uY2VwdHVhbGx5LCBpdCBp cyBxdWl0ZSBleHBlbnNpdmUgb24NCj4gdGhlIHdpcmUsIGVzcGVjaWFsbHkgd2l0aCBJUHY2IGFk ZHJlc3Nlcy4NCg0KUGVyc29uYWxseSBJIGFncmVlLiBIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHRo ZXJlIGFyZSBhIGxvdCBvZiBTUHMgd2hvIGFyZSBpbiBmYXZvciBvZiBjYXJyeWluZyBhIHN0YWNr IG9mIElQdjYgYWRkcmVzc2VzIG9uIHRoZSBJUHY2IHBhY2tldC4gRm9yIG1vcmUgZGV0YWlscywg cGxlYXNlIHNlZSB0aGUgSVB2Ni1TUiB1c2UgY2FzZSBkcmFmdC4NCg0KPiBBIHN0YWNrIG9mIE1Q TFMgbGFiZWxzIGlzIGFsc28gY29uY2VwdHVhbGx5IHNpbXBsZSwgYnV0IHRoZSB1c2Ugb2YgTVBM UyBpcyBub3QNCj4gdW5pdmVyc2FsLCBlc3BlY2lhbGx5IHdpdGhpbiBkYXRhIGNlbnRlciBlbnZp cm9ubWVudHMuICAgQWxzbywgdGhpcyB1c2Ugb2YgdGhlDQoNCldpdGhpbiBkYXRhIGNlbnRlciBl bnZpcm9ubWVudHMgYXMgeW91IG1lbnRpb25lZCwgdGhlIE1QTFMgbGFiZWwgc3RhY2sgd291bGQg anVzdCBiZSB1c2VkIGZvciByZXByZXNlbnRpbmcgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgcGF0aCwg YW5kIHlvdSBjb3VsZCBzdGlsbCB1c2UgSVAtYmFzZWQgdHVubmVscyB0byBmb3J3YXJkIHBhY2tl dHMgZnJvbSBvbmUgc2VydmljZSBub2RlIHRvIGFub3RoZXIgKGZvciBtb3JlIGRldGFpbHMsIHNl ZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctaXNsYW5kcy1jb25u ZWN0aW9uLW92ZXItaXAtMDApLiBJbiBvdGhlciB3b3JkLCB0aGUgTVBMUyBsYWJlbCBzdGFjayBw bGF5cyB0aGUgc2ltaWxhciByb2xlIG9mIHRoZSBzZXJ2aWNlIHBhdGggSUQuDQoNCj4gTVBMUyBs YWJlbHMgaXMgc29tZXdoYXQgZGlmZmVyZW50LCBzZW1hbnRpY2FsbHksIGFuZCBjb3VsZCBjYXVz ZSBpc3N1ZXMgaWYgdXNlZA0KPiBjb25jdXJyZW50bHkgd2l0aCB0cmFkaXRpb25hbCBNUExTIHVz ZSBjYXNlcy4gICBFc3BlY2lhbGx5IGdpdmVuIHRoYXQgZXhpc3RpbmcNCj4gTVBMUyBsYWJlbHMg YXJlIGRvd25zdHJlYW0gYWxsb2NhdGVkIGJ1dCBTRkMgaXMgZXNzZW50aWFsbHkgc291cmNlIHJv dXRlZC4NCg0KQSBNUExTIGxhYmVsIHN0YWNrIGNhbiBiZSB1c2VkIHRvIHJlYWxpemUgdGhlIHNv dXJjZSByb3V0aW5nIHBhcmFkaWdtLCBzZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZmlsc2ZpbHMtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTAxIGFuZCBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncmVkbGVyLXNwcmluZy1tcGxzLTAzLiANCg0KPiBQZXJo YXBzIHRoYXQgaXNzdWUgY291bGQgYmUgc29sdmVkLCBidXQgYXQgdGhlIGV4cGVuc2Ugb2YgYSBt b3JlIGNvbXBsZXggYW5kDQo+IGludmFzaXZlIGNvbnRyb2wgcGxhbmUuDQoNCkhvdyB0byBzaW1w bHkgdXNlIHRoZSBNUExTIGxhYmVsIHN0YWNrIHRvIHJlYWxpemUgdGhlIFNGQyBoYXMgYmVlbiBk ZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXNm Yy11c2UtY2FzZS0wMC4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCg0KPiAgICBSb24NCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFh1eGlhb2h1DQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTgsIDIwMTQgNTowMCBBTQ0KPiBUbzog c2ZjQGlldGYub3JnDQo+IENjOiBzcHJpbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3NmY10gV2h5 IFRyYW5zcG9ydCBEZXBlbmRlbmNlIGlzIGRlZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EDQo+ IEFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+IA0KPiBI aSBhbGwsDQo+IA0KPiBJdCBzYWlkIGluIHNlY3Rpb24gMi42LiAgVHJhbnNwb3J0IERlcGVuZGVu Y2Ugb2YgdGhlIFBTIGRyYWZ0Og0KPiANCj4gICAiU2VydmljZSBmdW5jdGlvbnMgY2FuIGFuZCB3 aWxsIGJlIGRlcGxveWVkIGluIG5ldHdvcmtzIHdpdGggYSByYW5nZQ0KPiAgICBvZiB0cmFuc3Bv cnRzLCBpbmNsdWRpbmcgdW5kZXIgYW5kIG92ZXJsYXlzLiAgVGhlIGNvdXBsaW5nIG9mIHNlcnZp Y2UNCj4gICAgZnVuY3Rpb25zIHRvIHRvcG9sb2d5IHJlcXVpcmVzIHNlcnZpY2UgZnVuY3Rpb25z IHRvIHN1cHBvcnQgbWFueQ0KPiAgICB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbnMgb3IgZm9yIGEg dHJhbnNwb3J0IGdhdGV3YXkgZnVuY3Rpb24gdG8gYmUNCj4gICAgcHJlc2VudC4iDQo+IA0KPiBB c3N1bWUgdGhlIGZ1bmN0aW9uIG9mIHNlcnZpY2UgY2hhaW4gY2FuIGJlIGRpdmlkZWQgaW50byB0 d28gbGF5ZXJzOiBvbmUgaXMgdGhlDQo+IHNlcnZpY2UgcGF0aCBsYXllciB3aGljaCBpcyByZXNw b25zaWJsZSBmb3Igc3RlZXJpbmcgdGhlIHBhY2tldHMgYWxvbmcgdGhlIHNlcnZpY2UNCj4gcGF0 aCwgdGhlIG90aGVyIGlzIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGxheWVyIHdoaWNoIGlzIHJlc3Bv bnNpYmxlIGZvciBhcHBseWluZyBhDQo+IGdpdmVuIHNlcnZpY2UgdG8gdGhlIHBhY2tldC4gSSBh Z3JlZSB0aGF0IHRyYW5zcG9ydCBkZXBlbmRlbmNlIGlzIGJhZCBmb3IgdGhlDQo+IHNlcnZpY2Ug ZnVuY3Rpb24gbGF5ZXIuIEhvd2V2ZXIsIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdHJhbnNwb3J0 IGRlcGVuZGVuY2UNCj4gaXMgYWxzbyBiYWQgZm9yIHRoZSBzZXJ2aWNlIHBhdGggbGF5ZXIuIElu IGZhY3QsIHRoZXJlIGFyZSBvbmx5IHR3byB1bmRlcmxheQ0KPiB0cmFuc3BvcnRzIChpLmUuLCBJ UCBhbmQgTVBMUykgd2hpY2ggbmVlZCB0byBiZSBjb25zaWRlcmVkIGZvciBzZXJ2aWNlIGNoYWlu Lg0KPiBUaGVyZWZvcmUsIHdlIGp1c3QgbmVlZCB0byBsZXZlcmFnZSB0aGUgc291cmNlIHJvdXRp bmcgY2FwYWJpbGl0eSBhc3NvY2lhdGVkIHdpdGgNCj4gSVAgb3IgTVBMUyB0byByZWFsaXplIHRo ZSBmdW5jdGlvbiBvZiB0aGUgc2VydmljZSBwYXRoIGxheWVyLiBUaGF0J3MgdG8gc2F5LCB3ZSBj YW4NCj4gdXNlIGFuIG9yZGVyZWQgbGlzdCBvZiBJUCBhZGRyZXNzZXMgb3IgTVBMUyBsYWJlbHMg Y2FycmllZCBpbiB0aGUgcGFja2V0IHRvDQo+IHJlcHJlc2VudCB0aGUgc2VydmljZSBwYXRoLiBB IE1QTFMgbGFiZWwgaW4gdGhlIG9yZGVyZWQgbGlzdCBvZiBNUExTIGxhYmVscyAoaS5lLiwgYQ0K PiBNUExTIGxhYmVsIHN0YWNrKSBvciBhbiBJUCBhZGRyZXNzIGluIHRoZSBvcmRlcmVkIGxpc3Qg b2YgSVAgYWRkcmVzc2VzIGNhbiBiZSB1c2VkDQo+IHRvIGluZGljYXRlIGVpdGhlciBhIHNlcnZp Y2Ugbm9kZSB3aXRoaW4gdGhlIHNlcnZpY2UgcGF0aCBvciBhIHNlcnZpY2UgZnVuY3Rpb24gb24N Cj4gYSBnaXZlbiBzZXJ2aWNlIG5vZGUuIE5vdGUgdGhhdCBNUExTIGxhYmVscyBhbmQgSVAgYWRk cmVzc2VzIGhhdmUgYmVlbg0KPiBzdWNjZXNzZnVsbHkgdXNlZCBmb3IgaW5kaWNhdGluZyBzZXJ2 aWNlcyAoZS5nLiwgVlBOIGxhYmVscyBhbmQgbXVsdGljYXN0IGFkZHJlc3Nlcw0KPiBpbiB0aGUg cmFuZ2Ugb2YgMjI0LjAuMC54IG9yIEZGMDI6OnggKS4NCj4gDQo+IE9mIGNvdXJzZSwgaWYgeW91 IHN0aWxsIHRoaW5rIHRoZXJlIGFyZSB0b28gbXVjaCB3b3JrIHRvIGRvLCB5b3UgY291bGQgYWN0 dWFsbHkNCj4gb25seSBjb25zaWRlciB0aGUgTVBMUy1iYXNlZCBhcHByb2FjaCAoaS5lLiwgdXNp bmcgYSBNUExTIGxhYmVsIHN0YWNrIHRvDQo+IHJlcHJlc2VudCBhIHNlcnZpY2UgcGF0aCkgc2lu Y2UgaXQgY291bGQgYWxzbyBiZSBhcHBsaWNhYmxlIGluIGJvdGggSVB2NCBhbmQgSVB2Ng0KPiBu ZXR3b3JrcyB3aXRoIHRoZSBoZWxwIG9mIGFueSBraW5kIG9mIE1QTFMgb3ZlciBJUCBlbmNhcHN1 bGF0aW9uIHRlY2hub2xvZ2llcy4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0K PiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+ILeiy83K sbzkOiAyMDE0xOo01MIxN8jVIDM6MTgNCj4gPiDK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KPiA+ILOty806IHNmY0BpZXRmLm9yZw0KPiA+INb3zOI6IFtzZmNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KPiA+DQo+ID4NCj4gPiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuDQo+ID4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgV29ya2luZw0KPiA+IEdyb3VwIG9mIHRoZSBJRVRG Lg0KPiA+DQo+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIFByb2JsZW0gU3RhdGVtZW50DQo+ID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBQ YXVsIFF1aW5uDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBUaG9tYXMgTmFkZWF1DQo+ ID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0 LnR4dA0KPiA+IAlQYWdlcyAgICAgICAgICAgOiAxOA0KPiA+IAlEYXRlICAgICAgICAgICAgOiAy MDE0LTA0LTE2DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IHByb3Zp ZGVzIGFuIG92ZXJ2aWV3IG9mIHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiA+ICAg IGRlcGxveW1lbnQgb2Ygc2VydmljZSBmdW5jdGlvbnMgKHN1Y2ggYXMgZmlyZXdhbGxzLCBsb2Fk IGJhbGFuY2VycykNCj4gPiAgICBpbiBsYXJnZS1zY2FsZSBlbnZpcm9ubWVudHMuICBUaGUgdGVy bSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzDQo+ID4gICAgdXNlZCB0byBkZXNjcmliZSB0 aGUgZGVmaW5pdGlvbiBhbmQgaW5zdGFudGlhdGlvbiBvZiBhbiBvcmRlcmVkIHNldA0KPiA+ICAg IG9mIGluc3RhbmNlcyBvZiBzdWNoIHNlcnZpY2UgZnVuY3Rpb25zLCBhbmQgdGhlIHN1YnNlcXVl bnQgInN0ZWVyaW5nIg0KPiA+ICAgIG9mIHRyYWZmaWMgZmxvd3MgdGhyb3VnaCB0aG9zZSBzZXJ2 aWNlIGZ1bmN0aW9ucy4NCj4gPg0KPiA+ICAgIFRoZSBzZXQgb2YgZW5hYmxlZCBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWlucyByZWZsZWN0IG9wZXJhdG9yIHNlcnZpY2UNCj4gPiAgICBvZmZlcmluZ3Mg YW5kIGlzIGRlc2lnbmVkIGluIGNvbmp1bmN0aW9uIHdpdGggYXBwbGljYXRpb24gZGVsaXZlcnkN Cj4gPiAgICBhbmQgc2VydmljZSBhbmQgbmV0d29yayBwb2xpY3kuDQo+ID4NCj4gPg0KPiA+IFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3Rh dGVtZW50Lw0KPiA+DQo+ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtcHJv YmxlbS1zdGF0ZW1lbnQtMDQNCj4gPg0KPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNA0KPiA+DQo+ID4NCj4gPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzZmMgbWFpbGluZyBsaXN0DQo+ID4gc2Zj QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2Zj IG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Mon Apr 21 03:29:13 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 10D5C1A01F4; Mon, 21 Apr 2014 03:29:11 -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 LLFd2AyWdN_F; Mon, 21 Apr 2014 03:29:07 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD21A01EA; Mon, 21 Apr 2014 03:29:06 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so3780006iec.29 for ; Mon, 21 Apr 2014 03:29:01 -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=5LUc3UxhVajQZJRe83f/XpLfm7v1gSVTP5IOWaJRySA=; b=nIaV9oGGX6QgXp6LCnD5B9JIgmn6fhkEMjtV9VQybIBkF8/5nNixTSxS1ZQa7E4jIW AWNm5vWRPRFFyFUqhoQ1ssdlh/rUJR6DilYpXq1wdvRdExqqO5loNJW5p9jJ9/3UqLgk FVvN8m8n2R459V5cloSlN8h7QcSuwVcSqHOGsmcn5N1Dk3yesOUEhpN+5ZaKdLwhqeHg V2NFxV1tzzqjbMT/b6pzFO3rzHpPS2YguL8/dPCgD9ECvxXkbymvL1vJoEwKsofascxj jtYfeVJz5m+PZtVhdb5KaVytzqKr5xRA8qyl47XjmNJGSjgQ56+TM9PMQ/S7qpFH9Vjp Apuw== MIME-Version: 1.0 X-Received: by 10.43.141.12 with SMTP id jc12mr30586540icc.21.1398076141874; Mon, 21 Apr 2014 03:29:01 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 21 Apr 2014 03:29:01 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> Date: Mon, 21 Apr 2014 12:29:01 +0200 X-Google-Sender-Auth: IcSyOy8eHPYaWLpK0cwNvCGe6dg Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: multipart/alternative; boundary=001a11c24ac2ce339b04f78af710 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/NYb9Xjn7n5xXsQGXDDkbDGJQ5uQ Cc: "spring@ietf.org" , "sfc@ietf.org" , Ron Parker Subject: Re: [spring] [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.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, 21 Apr 2014 10:29:11 -0000 --001a11c24ac2ce339b04f78af710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xu, How to simply use the MPLS label stack to realize the SFC has been > described in http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00. > Any comments are welcome. > =E2=80=8BThe draft says:=E2=80=8B "that packet, SN1 could further consume the metadata contained in the NSH and meanwhile decrease the service index value within the NSH by on =E2=80=8Be=E2=80=8B "=E2=80=8B I would observe after reading this draft that S =E2=80=8Bx service node may not be capable of handling NSH of any sort (inc= luding SR header - be it MPLS label stack or IPv6 EHs) therefor much more then just decreasing the index value is required at SNx. =E2=80=8BIt seems that to realize any service chain via most of today's ser= vice nodes a full removal of NSH and re-application is required at directly attached SNs. That actually means that network needs to carry the state pretty much out of band. Such state could be carried within routing protocols (today BGP is used for that in L3VPN case) or by new overlay control plane - same as is used to carry the metadata. Cheers, R. --001a11c24ac2ce339b04f78af710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xu,
How = to simply use the MPLS label stack to realize the SFC has been described in= http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00. Any comments are welcome.

<= div>



--001a11c24ac2ce339b04f78af710-- From nobody Mon Apr 21 18:12:41 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 13A3B1A00FD; Mon, 21 Apr 2014 18:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.172 X-Spam-Level: X-Spam-Status: No, score=-4.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 ywS4MF81ZxNz; Mon, 21 Apr 2014 18:12:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8A821A0110; Mon, 21 Apr 2014 18:12:31 -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 BDI61394; Tue, 22 Apr 2014 01:12:25 +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; Tue, 22 Apr 2014 02:11:47 +0100 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, 22 Apr 2014 02:12:23 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 09:12:17 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWwO2ZN9DNYdRwEi3MZ5fyWQNNpsbucIA//+jH4CAAXps8A== Date: Tue, 22 Apr 2014 01:12:17 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@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: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/BXQDulcKf-bT99gnhG8CumgPakA Cc: "spring@ietf.org" , "sfc@ietf.org" , Ron Parker Subject: [spring] =?utf-8?b?562U5aSNOiBbc2ZjXSBXaHkgVHJhbnNwb3J0IERlcGVu?= =?utf-8?q?dence_is_deemed_as_a_problem=3F//re=3A_I-D_Action=3A_draft-ietf?= =?utf-8?q?-sfc-problem-statement-04=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, 22 Apr 2014 01:12:35 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQrlj5Hku7bkuro6IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1 a0BnbWFpbC5jb21dIOS7o+ihqCBSb2JlcnQgUmFzenVrDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ0 5pyIMjHml6UgMTg6MjkNCuaUtuS7tuS6ujogWHV4aWFvaHUNCuaKhOmAgTogUm9uIFBhcmtlcjsg c2ZjQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtzZmNdIFdoeSBUcmFu c3BvcnQgRGVwZW5kZW5jZSBpcyBkZWVtZWQgYXMgYSBwcm9ibGVtPy8vcmU6IEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KDQpIaSBYdSwNCg0KSG93 IHRvIHNpbXBseSB1c2UgdGhlIE1QTFMgbGFiZWwgc3RhY2sgdG8gcmVhbGl6ZSB0aGUgU0ZDIGhh cyBiZWVuIGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1z cHJpbmctc2ZjLXVzZS1jYXNlLTAwLiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCuKAi1Ro ZSBkcmFmdCBzYXlzOuKAiw0KDQoidGhhdCBwYWNrZXQsIFNOMSBjb3VsZCBmdXJ0aGVyIGNvbnN1 bWUgdGhlIG1ldGFkYXRhIGNvbnRhaW5lZCBpbiB0aGUNCg0KTlNIIGFuZCBtZWFud2hpbGUgZGVj cmVhc2UgdGhlIHNlcnZpY2UgaW5kZXggdmFsdWUgd2l0aGluIHRoZSBOU0ggYnkNCg0KDQoNCm9u DQoNCuKAi2XigIsNCg0KDQoNCiLigIsNCg0KSSB3b3VsZCBvYnNlcnZlIGFmdGVyIHJlYWRpbmcg dGhpcyBkcmFmdCB0aGF0IFMNCuKAi3ggc2VydmljZSBub2RlIG1heSBub3QgYmUgY2FwYWJsZSBv ZiBoYW5kbGluZyBOU0ggb2YgYW55IHNvcnQgKGluY2x1ZGluZyBTUiBoZWFkZXIgLSBiZSBpdCBN UExTIGxhYmVsIHN0YWNrIG9yIElQdjYgRUhzKSB0aGVyZWZvciBtdWNoIG1vcmUgdGhlbiBqdXN0 IGRlY3JlYXNpbmcgdGhlIGluZGV4IHZhbHVlIGlzIHJlcXVpcmVkIGF0IFNOeC4NCg0K4oCLSXQg c2VlbXMgdGhhdCB0byByZWFsaXplIGFueSBzZXJ2aWNlIGNoYWluIHZpYSBtb3N0IG9mIHRvZGF5 J3Mgc2VydmljZSBub2RlcyBhIGZ1bGwgcmVtb3ZhbCBvZiBOU0ggYW5kIHJlLWFwcGxpY2F0aW9u IGlzIHJlcXVpcmVkIGF0IGRpcmVjdGx5IGF0dGFjaGVkIFNOcy4NCg0KW1hpYW9odV0gWW91ciBv YnNlcnZhdGlvbiBpcyBjb3JyZWN0LiBUaGUgU0YgcHJveHkgbXVzdCBzdHJpcCB0aGUgTlNIIGFu ZCB0aGUgU1IgaGVhZGVyIGJlZm9yZSBzZW5kaW5nIHRoZSBwYWNrZXRzIHRvIHRoZSBkaXJlY3Rs eSBhdHRhY2hlZCBsZWdhY3kgc2VydmljZSBmdW5jdGlvbnMuIFdoZW4gdGhlIHBhY2tldHMgd2Fz IHJldHVybmVkIGJ5IHNlcnZpY2UgZnVuY3Rpb25zLCB0aGUgU0YgcHJveHkgbXVzdCByZWltcG9z ZSB0aG9zZSBoZWFkZXJzIG9uIHRoZSBwYWNrZXRzLiBNZWFud2hpbGUsIHRoZSBTRiBwcm94eSBt dXN0IGRlY3JlYXNlIHRoZSBzZXJ2aWNlIGluZGV4IHZhbHVlIGJ5IDEuDQoNClRoYXQgYWN0dWFs bHkgbWVhbnMgdGhhdCBuZXR3b3JrIG5lZWRzIHRvIGNhcnJ5IHRoZSBzdGF0ZSBwcmV0dHkgbXVj aCBvdXQgb2YgYmFuZC4gU3VjaCBzdGF0ZSBjb3VsZCBiZSBjYXJyaWVkIHdpdGhpbiByb3V0aW5n IHByb3RvY29scyAodG9kYXkgQkdQIGlzIHVzZWQgZm9yIHRoYXQgaW4gTDNWUE4gY2FzZSkgb3Ig YnkgbmV3IG92ZXJsYXkgY29udHJvbCBwbGFuZSAtIHNhbWUgYXMgaXMgdXNlZCB0byBjYXJyeSB0 aGUgbWV0YWRhdGEuDQoNCltYaWFvaHVdIERpZCB5b3UgbWVhbiB0aGF0IHRoZSBtZXRhZGF0YSBz aG91bGQgYmUgdHJhbnNmZXJyZWQgdGhyb3VnaCB0aGUgY29udHJvbCBwbGFuZT8NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCkNoZWVycywNClIuDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4gcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Sb2JlcnQgUmFzenVr PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bp l7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj40PC9zcGFuPuaciDxzcGFuIGxhbmc9 IkVOLVVTIj4yMTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE4OjI5PGJyPg0KPC9zcGFu PjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFh1eGlhb2h1PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzsg c3ByaW5nQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbc2ZjXSBXaHkgVHJhbnNwb3J0IERl cGVuZGVuY2UgaXMgZGVlbWVkIGFzIGEgcHJvYmxlbT8vL3JlOiBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkhpIFh1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvdyB0byBzaW1wbHkgdXNlIHRoZSBNUExTIGxhYmVs IHN0YWNrIHRvIHJlYWxpemUgdGhlIFNGQyBoYXMgYmVlbiBkZXNjcmliZWQgaW4NCjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNwcmluZy1zZmMtdXNlLWNhc2Ut MDAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1 LXNwcmluZy1zZmMtdXNlLWNhc2UtMDA8L2E+LiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgZHJhZnQgc2F5czo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPnRoYXQgcGFja2V0LCBTTjEgY291bGQgZnVydGhlciBjb25zdW1lIHRoZSBtZXRhZGF0YSBj b250YWluZWQgaW4gdGhlPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+TlNIIGFuZCBtZWFud2hpbGUgZGVjcmVhc2UgdGhlIHNlcnZpY2UgaW5kZXggdmFsdWUg d2l0aGluIHRoZSBOU0ggYnkmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPm9uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PuKAi2XigIs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+JnF1b3Q7 4oCLPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHdvdWxkIG9ic2VydmUgYWZ0ZXIg cmVhZGluZyB0aGlzIGRyYWZ0IHRoYXQgUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCLPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnggc2VydmljZSBub2RlIG1heSBub3QgYmUgY2FwYWJsZSBvZiBoYW5kbGluZyBOU0ggb2Yg YW55IHNvcnQgKGluY2x1ZGluZyBTUiBoZWFkZXIgLSBiZSBpdCBNUExTIGxhYmVsIHN0YWNrIG9y IElQdjYNCiBFSHMpIHRoZXJlZm9yIG11Y2ggbW9yZSB0aGVuIGp1c3QgZGVjcmVhc2luZyB0aGUg aW5kZXggdmFsdWUgaXMgcmVxdWlyZWQgYXQgU054LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FtYnJpYSBNYXRoJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+SXQgc2VlbXMgdGhhdCB0byByZWFsaXplIGFueSBzZXJ2aWNlIGNoYWluIHZpYSBtb3N0 IG9mIHRvZGF5J3Mgc2VydmljZSBub2RlcyBhIGZ1bGwgcmVtb3ZhbCBvZiBOU0ggYW5kIHJlLWFw cGxpY2F0aW9uDQogaXMgcmVxdWlyZWQgYXQgZGlyZWN0bHkgYXR0YWNoZWQgU05zLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltYaWFvaHVdIFlvdXIgb2JzZXJ2YXRpb24gaXMg Y29ycmVjdC4gVGhlIFNGIHByb3h5IG11c3Qgc3RyaXAgdGhlIE5TSCBhbmQgdGhlIFNSIGhlYWRl ciBiZWZvcmUgc2VuZGluZyB0aGUgcGFja2V0cyB0byB0aGUgZGlyZWN0bHkgYXR0YWNoZWQgbGVn YWN5DQogc2VydmljZSBmdW5jdGlvbnMuIFdoZW4gdGhlIHBhY2tldHMgd2FzIHJldHVybmVkIGJ5 IHNlcnZpY2UgZnVuY3Rpb25zLCB0aGUgU0YgcHJveHkgbXVzdCByZWltcG9zZSB0aG9zZSBoZWFk ZXJzIG9uIHRoZSBwYWNrZXRzLiBNZWFud2hpbGUsIHRoZSBTRiBwcm94eSBtdXN0IGRlY3JlYXNl IHRoZSBzZXJ2aWNlIGluZGV4IHZhbHVlIGJ5IDEuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+VGhhdCBhY3R1YWxseSBtZWFucyB0aGF0IG5ldHdvcmsgbmVl ZHMgdG8gY2FycnkgdGhlIHN0YXRlIHByZXR0eSBtdWNoIG91dCBvZiBiYW5kLiBTdWNoIHN0YXRl IGNvdWxkIGJlIGNhcnJpZWQgd2l0aGluIHJvdXRpbmcgcHJvdG9jb2xzICh0b2RheSBCR1AgaXMg dXNlZCBmb3IgdGhhdCBpbiBMM1ZQTiBjYXNlKSBvciBieQ0KIG5ldyBvdmVybGF5IGNvbnRyb2wg cGxhbmUgLSBzYW1lIGFzIGlzIHVzZWQgdG8gY2FycnkgdGhlIG1ldGFkYXRhLiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWGlhb2h1XSBEaWQgeW91IG1lYW4gdGhhdCB0aGUg bWV0YWRhdGEgc2hvdWxkIGJlIHRyYW5zZmVycmVkIHRocm91Z2ggdGhlIGNvbnRyb2wgcGxhbmU/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhpYW9odTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q2hlZXJzLDxicj4NClIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_-- From nobody Tue Apr 22 00:28: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 1A4F61A010F; Tue, 22 Apr 2014 00:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MIME_8BIT_HEADER=0.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 G1W9vuILyR_L; Tue, 22 Apr 2014 00:28:12 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 057B11A010E; Tue, 22 Apr 2014 00:28:11 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so4848797ier.41 for ; Tue, 22 Apr 2014 00:28:06 -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=D8GfO5K7MjKf1NRiBJauqim/fZq2BJMcWLdhzV8dPdM=; b=Lx3no+bYH4CU/qvuPiimQfMBIo9SkoGk2+TFRsZV+dLnLLB1Q8qNZfH4poILtqJKtj O207FXFVJ9UBD19tiEOvTfV4D2ATbyEmx/FiT9qws6jeyHuMjSx2PBPEu5EpBFEctJxS adBcSmgL1p6rDrZGJJe2rVd5kxgQolIQGY6rdQgdQJLZVQM9fBJD5KmFbtpMPgYbXErC 6zrVs2kk3GKpSB5BJjpSSsTmevNGkahU4md4twOPSjtPJbV/j/1QUs9L1+kPWuJqbN0D tVVw4mLhNjx0QYSlSyKTcmwBx2Zn8lmdIhb97qX+ncrysL9qk5K9nI07M3mBtSErzNYw oikA== MIME-Version: 1.0 X-Received: by 10.50.82.73 with SMTP id g9mr27813055igy.0.1398151686729; Tue, 22 Apr 2014 00:28:06 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Tue, 22 Apr 2014 00:28:06 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> Date: Tue, 22 Apr 2014 09:28:06 +0200 X-Google-Sender-Auth: NDmCc_I7BkpOze3cKHhrwMhmosg Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/3_3ihx3QfAblh2c1De_obvuzMCk Cc: "spring@ietf.org" , Ron Parker , "sfc@ietf.org" Subject: Re: [spring] =?utf-8?b?W3NmY10g562U5aSNOiBXaHkgVHJhbnNwb3J0IERlcGVu?= =?utf-8?q?dence_is_deemed_as_a_problem=3F//re=3A_I-D_Action=3A_draft-ietf?= =?utf-8?q?-sfc-problem-statement-04=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, 22 Apr 2014 07:28:13 -0000 > [Xiaohu] Your observation is correct. The SF proxy must strip the NSH and the SR header before sending the packets to the directly attached legacy service functions. When the packets was returned by service functions, the SF proxy must reimpose those headers on the packets. Meanwhile, the SF proxy must decrease the service index value by 1. > Good so we agree on that point. What actually worries me a bit that to "reimpose" you need to do full classification again - just like you do it on all ingress nodes. Moreover how you reimpose could be also a function of service product. > > That actually means that network needs to carry the state pretty much out of band. Such state could be carried within routing protocols (today BGP is used for that in L3VPN case) or by new overlay control plane - same as is used to carry the metadata. > > > [Xiaohu] Did you mean that the metadata should be transferred through the control plane? How else would you carry it ? It's not data plane after all. Of course perhaps your definition of control plane = routing protocols, but I did not mean that. Control plane is just a information overlay of some form. Just like IN networks in well known telephone networks :) Cheers, R. From nobody Wed Apr 23 01:20:00 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 34D511A010F; Wed, 23 Apr 2014 01:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MIME_8BIT_HEADER=0.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 gjr6Iv8asWWF; Wed, 23 Apr 2014 01:19:53 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B29BC1A00CF; Wed, 23 Apr 2014 01:19:53 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id h18so4031247igc.7 for ; Wed, 23 Apr 2014 01:19:48 -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=u9H1KZ1I6wOUeKUQS+sBg8hIDGc4q3y3PXO31aCi0FE=; b=IjAJfu6T7l0d3Tz4qOUDxeab6mvOhxqFNzbPPDG9hE3xgoXVivcr09hyPT+6nlHz1D 4YYWJAfdvr4rMqX+WSQQiIVhWDOv/dcmQUSl1F24olNwdVeSSb2hXaiJhNP4PzS7oubF igGjnzbHycPHzh1Keq6YF53cut4tohSAjUljW3DG37Vodo+Fq1Pcp6dlRiwdZgFYAnVD UmXdO6WQdG7eHx0n+z/0uQrT0XjtpGY33c6rFazhMxmZFSRrVAVmKWrSbkWoMlBTtgkp px7B9U2DkXFKEFYjkGE0bFtuttUp7UZmvKpn0YZDaHwhEbTecd158d2ZB2C02QkBCqQq Yn3g== MIME-Version: 1.0 X-Received: by 10.50.109.230 with SMTP id hv6mr857032igb.9.1398241188074; Wed, 23 Apr 2014 01:19:48 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 23 Apr 2014 01:19:47 -0700 (PDT) In-Reply-To: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> Date: Wed, 23 Apr 2014 10:19:47 +0200 X-Google-Sender-Auth: Pk3PbcGiqu8sLwkGxym1p2YLz5o Message-ID: From: Robert Raszuk To: "Songhaibin (A)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/spring/tralbtSrvi7-k96UiWLAg_KEjao Cc: Ron Parker , Xuxiaohu , "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [spring] =?utf-8?b?W3NmY10g562U5aSNOiBXaHkgVHJhbnNwb3J0IERlcGVu?= =?utf-8?q?dence_is_deemed_as_a_problem=3F//re=3A_I-D_Action=3A_draft-ietf?= =?utf-8?q?-sfc-problem-statement-04=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: Wed, 23 Apr 2014 08:19:58 -0000 Hi Haibin, Actually my comments were in regards to non transparent SF (your section 3.= 2). And honestly I am not consider those as legacy. IMO even modern service nodes should not be forced to "handle" SF headers. So much more focus should be made to make the solutions well understood as those directly have great impact on the entire network control plane side. Simply stating removing all the packet/flow state from the network is not possible. Cheers, R. On Wed, Apr 23, 2014 at 9:06 AM, Songhaibin (A) wr= ote: > Hi, > > > -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Robert Raszuk >> Sent: Tuesday, April 22, 2014 3:28 PM >> To: Xuxiaohu >> Cc: spring@ietf.org; Ron Parker; sfc@ietf.org >> Subject: Re: [sfc] =E7=AD=94=E5=A4=8D: Why Transport Dependence is deeme= d as a >> problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt >> >> > [Xiaohu] Your observation is correct. The SF proxy must strip the NSH >> > and the >> SR header before sending the packets to the directly attached legacy ser= vice >> functions. When the packets was returned by service functions, the SF pr= oxy >> must reimpose those headers on the packets. Meanwhile, the SF proxy must >> decrease the service index value by 1. >> > >> >> Good so we agree on that point. >> >> What actually worries me a bit that to "reimpose" you need to do full >> classification again - just like you do it on all ingress nodes. >> >> Moreover how you reimpose could be also a function of service product. > > Actually we have a draft to talk about the legacy support. First, things = have to be classified according to whether the legacy service function inst= ance is transparent or not. Then if it is transparent, you can use differen= t fields in the packet to map to service header and then retrieval it again= . If not, things become much more complicated. Here is the link for the dra= ft. > https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/ > > BR, > -Haibin > >> >> >> > >> > That actually means that network needs to carry the state pretty much = out of >> band. Such state could be carried within routing protocols (today BGP is= used >> for that in L3VPN case) or by new overlay control plane - same as is use= d to >> carry the metadata. >> > >> > >> > [Xiaohu] Did you mean that the metadata should be transferred through = the >> control plane? >> >> >> How else would you carry it ? It's not data plane after all. Of course p= erhaps >> your definition of control plane =3D routing protocols, but I did not me= an that. >> >> Control plane is just a information overlay of some form. Just like IN n= etworks >> in well known telephone networks :) >> >> Cheers, >> R. >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 23 05:20: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 3205F1A035C for ; Wed, 23 Apr 2014 05:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272] 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 X7jEmGtzaZIQ for ; Wed, 23 Apr 2014 05:20:40 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA521A0345 for ; Wed, 23 Apr 2014 05:20:39 -0700 (PDT) Received: from [109.144.246.125] (helo=[10.210.2.187]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Wcw9x-0002Ja-Ov; Wed, 23 Apr 2014 13:20:17 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rob Shakir In-Reply-To: Date: Wed, 23 Apr 2014 13:20:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5388D290-F7F1-4D8C-9627-07E6CE616002@rob.sh> References: To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/eArc1Ssm4ZpQDLWcQGW-RLxpC4Y Cc: "spring@ietf.org" , "draft-previdi-spring-problem-statement@tools.ietf.org" Subject: Re: [spring] IPR Claims related to draft-previdi-spring-problem-statement 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, 23 Apr 2014 12:20:42 -0000 On 13 Mar 2014, at 21:10, Alvaro Retana (aretana) = wrote: > Hi! >=20 > In parallel to the WG Adoption Call for this draft, I want to formally = ask the authors (no additional contributors are listed in the latest = version of the draft) to please respond to this message indicating = whether or not you are aware of any relevant IPR. The draft will not = progress (pending the results of the WG Adoption Call) until we have = received a response from each author. >=20 > Note: Given that the draft should be representing use cases, there is = an expectation that no IPR is present. If there is, the WG will likely = ask you to remove any related text. Hi Alvaro, And again =97 sorry for the delay. I=92m not aware of any IPR claims = related to material discussed in this draft. Kind regards, r.= From nobody Wed Apr 23 06:56:45 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 7A6551A020F for ; Wed, 23 Apr 2014 06:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 TCwTvfZGG-OD for ; Wed, 23 Apr 2014 06:56:41 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEC61A03B3 for ; Wed, 23 Apr 2014 06:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3078; q=dns/txt; s=iport; t=1398261393; x=1399470993; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=L2TFHwmiWwkbvWbcmHmNX7Duf8fKKJc7gn7mBL5DFfY=; b=SQaRq1Ldn/dZErfhQDX9ANpBpGUxkmb/KH1yl2ij2o9FP4eQ95+gmSop 5k7H14hTI18CJ97sDHXhQXUi4+4dFsZ1V9e5kH0Uzxt/9WTClkj03KrMY JHDMlLSBdYnwnLmZjDUwj9d18Qp1zWY5c2CbWFWEMbwzD5lzualpkBy8+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAMnFV1OtJV2Y/2dsb2JhbABZgwZPV8QzgRkWdIIlAQEBAwE6PQcLAgEZAQIBAh8QMhcEAggCBBMJiDAIDc81F44tOIMegRUEmHWBN5EegzGCKw X-IronPort-AV: E=Sophos;i="4.97,912,1389744000"; d="scan'208";a="38071276" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 23 Apr 2014 13:56:33 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3NDuXgV023310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Apr 2014 13:56:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 08:56:33 -0500 From: "Stefano Previdi (sprevidi)" To: " ietf.org" Thread-Topic: New Version Notification for draft-filsfils-spring-segment-routing-00.txt Thread-Index: AQHPXvtu48JCnJO6aUagz1HKAOw2sw== Date: Wed, 23 Apr 2014 13:56:32 +0000 Message-ID: References: <20140423135341.9198.53109.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.209.108] 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/IBO6jQxwE26UUTAm6e8ADNXVE6I Subject: [spring] Fwd: New Version Notification for draft-filsfils-spring-segment-routing-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: Wed, 23 Apr 2014 13:56:43 -0000 FYI, just a filename change so to move the draft from rtg-wg to spring-wg. Thanks. s. Begin forwarded message: > From: > Subject: New Version Notification for draft-filsfils-spring-segment-routi= ng-00.txt > Date: April 23, 2014 3:53:41 PM GMT+02:00 > To: Rob Shakir , Wim Henderickx , Stefano Previdi , Ahmed Bashandy , Edward Crabbe , "Ahmed Bashandy" , Jeff Tantsura , Clarence Filsfils , Edward Crabbe , "Saku Ytti" , Stefano Previdi , Wim Henderickx , Bruno Decraene , Stephane Li= tkowski , Clarence Filsfils , Bruno Decraene , Igor Milojevic , Martin Horneffer , Jeff Tant= sura , Rob Shakir , Igor Mil= ojevic , Saku Ytti , "Martin Hornef= fer" , Stephane Litkowski >=20 >=20 > A new version of I-D, draft-filsfils-spring-segment-routing-00.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-filsfils-spring-segment-routing > Revision: 00 > Title: Segment Routing Architecture > Document date: 2014-04-23 > Group: Individual Submission > Pages: 28 > URL: http://www.ietf.org/internet-drafts/draft-filsfils-spring= -segment-routing-00.txt > Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-se= gment-routing/ > Htmlized: http://tools.ietf.org/html/draft-filsfils-spring-segment-= routing-00 >=20 >=20 > Abstract: > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through a controlled set of instructions, called > segments, by prepending 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 to enforce a flow through any topological path and > service chain while maintaining per-flow state only at the ingress > node to the SR domain. >=20 > The Segment Routing architecture can be directly applied to the MPLS > dataplane with no change on the forwarding plane. IGP-based segments > require minor extension to the existing link-state routing protocols. > Segment Routing can also be applied to IPv6 with a new type of > routing extension header. >=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 Wed Apr 23 18:24: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 311B11A0776 for ; Wed, 23 Apr 2014 18:24:39 -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 Ex6dUN9Kn-Sz for ; Wed, 23 Apr 2014 18:24:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id BB4AC1A0775 for ; Wed, 23 Apr 2014 18:24:35 -0700 (PDT) Received: from BL2PR05MB097.namprd05.prod.outlook.com (10.255.232.11) by BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) with Microsoft SMTP Server (TLS) id 15.0.921.12; Thu, 24 Apr 2014 01:24:29 +0000 Received: from DM2PR05CA026.namprd05.prod.outlook.com (10.141.241.16) by BL2PR05MB097.namprd05.prod.outlook.com (10.255.232.11) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 24 Apr 2014 01:24:28 +0000 Received: from BN1AFFO11FD054.protection.gbl (2a01:111:f400:7c10::129) by DM2PR05CA026.outlook.office365.com (2a01:111:e400:2464::16) with Microsoft SMTP Server (TLS) id 15.0.921.12 via Frontend Transport; Thu, 24 Apr 2014 01:24:28 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BN1AFFO11FD054.mail.protection.outlook.com (10.58.53.69) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Thu, 24 Apr 2014 01:24:28 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 23 Apr 2014 18:24:25 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s3O1ONV71141; Wed, 23 Apr 2014 18:24:23 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201404240124.s3O1ONV71141@magenta.juniper.net> To: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91290.1398302662.1@juniper.net> Date: Wed, 23 Apr 2014 18:24:23 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(458001)(189002)(199002)(23726002)(80976001)(46102001)(77096999)(19580395003)(19580405001)(83322001)(44976005)(4396001)(54356999)(6806004)(76482001)(87936001)(50986999)(79102001)(15975445006)(86362001)(84676001)(80022001)(46406003)(81342001)(20776003)(1941001)(47776003)(92726001)(92566001)(85852003)(50466002)(83072002)(99396002)(2009001)(77982001)(74662001)(74502001)(81542001)(16796002)(97736001)(31966008)(97756001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB097; H:P-EMF01-SAC.jnpr.net; FPR:BEDAF9F2.28929CCA.72D79B6F.C4E291C8.2015A; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Forefront-PRVS: 01917B1794 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/6zwmWosjOLJGuL8EXJfy2S53hzA Cc: spring@ietf.org Subject: [spring] use case vs requirements 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, 24 Apr 2014 01:24:39 -0000 Dear WG co-chairs, I am still waiting for your response to the e-mail I sent you (see below). Yakov. ------- Forwarded Message Date: Fri, 04 Apr 2014 11:54:50 -0700 From: Yakov Rekhter To: , cc: Subject: [spring] use case vs requirements Alvaro and John, The SPRING WG charter asks for "One or more documents describing SPRING use cases". Give that, could you, as the SPRING WG co-chairs, comment on whether the SPRING use cases document(s) should cover just the use cases, or should also include the SPRING architecture requirements. Yakov. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ------- End of Forwarded Message From nobody Thu Apr 24 06:16: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 1A8891A022E; Thu, 24 Apr 2014 06:16:17 -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 ucuxdPPHnMuO; Thu, 24 Apr 2014 06:16:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 157911A0192; Thu, 24 Apr 2014 06:16:15 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424131615.14114.11214.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 06:16:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/iJ5yBt2B4aSza7iR_OF1JZqDSfQ Cc: spring@ietf.org Subject: [spring] I-D Action: draft-previdi-spring-problem-statement-04.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, 24 Apr 2014 13:16:17 -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-previdi-spring-problem-statement-04.txt Pages : 18 Date : 2014-04-24 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-previdi-spring-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-previdi-spring-problem-statement-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-previdi-spring-problem-statement-04 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 Mon Apr 28 08:03:30 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 6CD6F1A0088; Wed, 23 Apr 2014 00:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.477 X-Spam-Level: * X-Spam-Status: No, score=1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 6QKePLDpmMAZ; Wed, 23 Apr 2014 00:06:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAE821A00A7; Wed, 23 Apr 2014 00:06:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDJ94774; Wed, 23 Apr 2014 07:06:33 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 08:05:38 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 08:06:32 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 23 Apr 2014 15:06:22 +0800 From: "Songhaibin (A)" To: Robert Raszuk , Xuxiaohu Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogV2h5IFRyYW5zcG9ydCBEZXBlbmRlbmNlIGlzIGRlZW1l?= =?gb2312?B?ZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1z?= =?gb2312?Q?fc-problem-statement-04.txt?= Thread-Index: AQHPXf1eQcMxCFyktUu1W9GbAFmBf5sextVg Date: Wed, 23 Apr 2014 07:06:21 +0000 Message-ID: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.109] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/VIeO7WMZjC5sNfdsXfSYEHAHnMk X-Mailman-Approved-At: Mon, 28 Apr 2014 08:03:28 -0700 Cc: "spring@ietf.org" , "sfc@ietf.org" , Ron Parker Subject: Re: [spring] =?gb2312?b?W3NmY10gtPC4tDogV2h5IFRyYW5zcG9ydCBEZXBlbmRl?= =?gb2312?b?bmNlIGlzIGRlZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EIEFjdGlvbjog?= =?gb2312?b?ZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0?= 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, 23 Apr 2014 07:06:46 -0000 SGksDQoNCg0KIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KPiBTZW50 OiBUdWVzZGF5LCBBcHJpbCAyMiwgMjAxNCAzOjI4IFBNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzog c3ByaW5nQGlldGYub3JnOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtzZmNdILTwuLQ6IFdoeSBUcmFuc3BvcnQgRGVwZW5kZW5jZSBpcyBkZWVtZWQgYXMgYQ0KPiBw cm9ibGVtPy8vcmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50 LTA0LnR4dA0KPiANCj4gPiBbWGlhb2h1XSBZb3VyIG9ic2VydmF0aW9uIGlzIGNvcnJlY3QuIFRo ZSBTRiBwcm94eSBtdXN0IHN0cmlwIHRoZSBOU0gNCj4gPiBhbmQgdGhlDQo+IFNSIGhlYWRlciBi ZWZvcmUgc2VuZGluZyB0aGUgcGFja2V0cyB0byB0aGUgZGlyZWN0bHkgYXR0YWNoZWQgbGVnYWN5 IHNlcnZpY2UNCj4gZnVuY3Rpb25zLiBXaGVuIHRoZSBwYWNrZXRzIHdhcyByZXR1cm5lZCBieSBz ZXJ2aWNlIGZ1bmN0aW9ucywgdGhlIFNGIHByb3h5DQo+IG11c3QgcmVpbXBvc2UgdGhvc2UgaGVh ZGVycyBvbiB0aGUgcGFja2V0cy4gTWVhbndoaWxlLCB0aGUgU0YgcHJveHkgbXVzdA0KPiBkZWNy ZWFzZSB0aGUgc2VydmljZSBpbmRleCB2YWx1ZSBieSAxLg0KPiA+DQo+IA0KPiBHb29kIHNvIHdl IGFncmVlIG9uIHRoYXQgcG9pbnQuDQo+IA0KPiBXaGF0IGFjdHVhbGx5IHdvcnJpZXMgbWUgYSBi aXQgdGhhdCB0byAicmVpbXBvc2UiIHlvdSBuZWVkIHRvIGRvIGZ1bGwNCj4gY2xhc3NpZmljYXRp b24gYWdhaW4gLSBqdXN0IGxpa2UgeW91IGRvIGl0IG9uIGFsbCBpbmdyZXNzIG5vZGVzLg0KPiAN Cj4gTW9yZW92ZXIgaG93IHlvdSByZWltcG9zZSBjb3VsZCBiZSBhbHNvIGEgZnVuY3Rpb24gb2Yg c2VydmljZSBwcm9kdWN0Lg0KDQpBY3R1YWxseSB3ZSBoYXZlIGEgZHJhZnQgdG8gdGFsayBhYm91 dCB0aGUgbGVnYWN5IHN1cHBvcnQuIEZpcnN0LCB0aGluZ3MgaGF2ZSB0byBiZSBjbGFzc2lmaWVk IGFjY29yZGluZyB0byB3aGV0aGVyIHRoZSBsZWdhY3kgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5j ZSBpcyB0cmFuc3BhcmVudCBvciBub3QuIFRoZW4gaWYgaXQgaXMgdHJhbnNwYXJlbnQsIHlvdSBj YW4gdXNlIGRpZmZlcmVudCBmaWVsZHMgaW4gdGhlIHBhY2tldCB0byBtYXAgdG8gc2VydmljZSBo ZWFkZXIgYW5kIHRoZW4gcmV0cmlldmFsIGl0IGFnYWluLiBJZiBub3QsIHRoaW5ncyBiZWNvbWUg bXVjaCBtb3JlIGNvbXBsaWNhdGVkLiBIZXJlIGlzIHRoZSBsaW5rIGZvciB0aGUgZHJhZnQuDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zb25nLXNmYy1sZWdhY3ktc2Yt bWFwcGluZy8NCg0KQlIsDQotSGFpYmluDQoNCj4gDQo+IA0KPiA+DQo+ID4gVGhhdCBhY3R1YWxs eSBtZWFucyB0aGF0IG5ldHdvcmsgbmVlZHMgdG8gY2FycnkgdGhlIHN0YXRlIHByZXR0eSBtdWNo IG91dCBvZg0KPiBiYW5kLiBTdWNoIHN0YXRlIGNvdWxkIGJlIGNhcnJpZWQgd2l0aGluIHJvdXRp bmcgcHJvdG9jb2xzICh0b2RheSBCR1AgaXMgdXNlZA0KPiBmb3IgdGhhdCBpbiBMM1ZQTiBjYXNl KSBvciBieSBuZXcgb3ZlcmxheSBjb250cm9sIHBsYW5lIC0gc2FtZSBhcyBpcyB1c2VkIHRvDQo+ IGNhcnJ5IHRoZSBtZXRhZGF0YS4NCj4gPg0KPiA+DQo+ID4gW1hpYW9odV0gRGlkIHlvdSBtZWFu IHRoYXQgdGhlIG1ldGFkYXRhIHNob3VsZCBiZSB0cmFuc2ZlcnJlZCB0aHJvdWdoIHRoZQ0KPiBj b250cm9sIHBsYW5lPw0KPiANCj4gDQo+IEhvdyBlbHNlIHdvdWxkIHlvdSBjYXJyeSBpdCA/IEl0 J3Mgbm90IGRhdGEgcGxhbmUgYWZ0ZXIgYWxsLiBPZiBjb3Vyc2UgcGVyaGFwcw0KPiB5b3VyIGRl ZmluaXRpb24gb2YgY29udHJvbCBwbGFuZSA9IHJvdXRpbmcgcHJvdG9jb2xzLCBidXQgSSBkaWQg bm90IG1lYW4gdGhhdC4NCj4gDQo+IENvbnRyb2wgcGxhbmUgaXMganVzdCBhIGluZm9ybWF0aW9u IG92ZXJsYXkgb2Ygc29tZSBmb3JtLiBKdXN0IGxpa2UgSU4gbmV0d29ya3MNCj4gaW4gd2VsbCBr bm93biB0ZWxlcGhvbmUgbmV0d29ya3MgOikNCj4gDQo+IENoZWVycywNCj4gUi4NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWls aW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo=